An MCP (Model Context Protocol) server that makes 3GPP specifications accessible to LLMs.
3GPP specifications are essential references for mobile and telecommunications engineering, but they are difficult for LLMs to work with effectively:
Too many documents - Thousands of specifications exist across multiple series, making it hard to find the right one.
Individual documents are too large - Many specs are hundreds of pages long, far exceeding typical context windows.
Distributed as Word files - Specs are published in .docx / .doc format and require conversion for text processing.
Heavy cross-referencing - Specs frequently reference each other; reading a single document in isolation gives an incomplete picture.
Information packed in tables and figures - Complex tables and flow diagrams carry critical details. This tool converts tables to Markdown and extracts embedded images for LLM viewing.
Version complexity - The same specification exists across multiple 3GPP releases, and identifying the correct version matters.
This tool addresses these challenges by parsing the .docx files, structuring the content by section, and storing everything in a SQLite database with full-text search (FTS5). An MCP server then exposes tools for searching, browsing by section, and following cross-references — letting an LLM navigate the specifications the way an engineer would.
Embedding-based RAG is a common way to improve accuracy on document Q&A, and RAG systems specialized for 3GPP documents exist (Telco-RAG, TelcoAI). This tool takes a simpler approach: instead of building a retrieval pipeline in front of the model, it gives the model search and navigation tools and lets it explore the specifications the way an engineer would — full-text search, then following the section hierarchy and cross-references. Since retrieval is plain FTS5 search over structured sections, there is no embedding model or vector database to run, and everything lives in a single SQLite file.
Measured on TeleQnA, this lifts accuracy on 3GPP standards questions by 6.5 to 12.0 percentage points across three model families. Most of that is having the text at all: a single BM25 query over the same database accounts for +7.8 to +9.6pt of it. The tool's own search is what separates them on questions whose answer sits more than one hop from the first retrieved passage — on tasks generated from the specifications themselves (protocol codes, ASN.1 structure, 5G SBI schemas) it answers and correctly cites 88-100%, beating that same BM25 baseline by +26 to +88 points on every task type and every model. See BENCHMARK.md.
Related MCP server: mcp-docs
# Homebrew
brew install higebu/tap/3gpp-mcp
# ...or with Go 1.26+
go install github.com/higebu/3gpp-mcp/cmd/3gpp-mcp@latestPrebuilt binaries are also available on the releases page. LibreOffice is optional (needed for .doc to .docx conversion and EMF/WMF image to PNG conversion).
Download and import specifications into the database. Temporary files are deleted after each spec is processed, minimizing disk usage.
# Download and import the latest version of every spec (all releases)
3gpp-mcp build --latest --db data/3gpp.db --convert-doc --convert-image
# ...or restrict to a single release
3gpp-mcp build --release 19 --db data/3gpp.db --convert-doc --convert-imageThis will scrape the 3GPP FTP archive, download ZIP files, extract and parse .docx files, and insert structured content into the SQLite database.
claude mcp add --scope user 3gpp -- 3gpp-mcp serve --db /path/to/data/3gpp.dbcode --add-mcp '{"name":"3gpp","command":"3gpp-mcp","args":["serve","--db","/path/to/data/3gpp.db"]}'Add to ~/.config/github-copilot/cli-mcp.json (create if it doesn't exist):
{
"mcpServers": {
"3gpp": {
"command": "3gpp-mcp",
"args": ["serve", "--db", "/path/to/data/3gpp.db"]
}
}
}codex mcp add --name 3gpp --command 3gpp-mcp --args serve --db /path/to/data/3gpp.dbAdd to your configuration file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"3gpp": {
"command": "3gpp-mcp",
"args": ["serve", "--db", "/path/to/data/3gpp.db"]
}
}
}Browse specifications in your browser by adding --web to the HTTP transport:
3gpp-mcp serve --db data/3gpp.db --transport http --addr :8080 --web
# MCP endpoint: http://localhost:8080/mcp/
# Web viewer: http://localhost:8080/Features: spec list with filtering, section viewer with TOC sidebar, full-text search with pagination, past-version browsing (versions are listed per spec and downloaded on demand, like the MCP tools), version comparison (structural summary and per-section diffs), embedded images, cross-reference links, OpenAPI definitions with syntax highlighting, KaTeX rendering of the LaTeX formulas the converter emits, dark mode, responsive design. Code blocks are syntax-highlighted per notation — ASN.1, Diameter, SIP/RTSP, SDP and XML (see Code blocks).
When the browser provides the W3C WebMCP API (document.modelContext, a Chrome origin trial as of 2026), the viewer registers all of its MCP tools with the browser at page load, so an in-browser agent can query the spec database directly. The registration is a thin same-origin passthrough to the /mcp/ endpoint — there is nothing to configure server-side, and browsers without the API are unaffected. During the origin trial, enable it locally via Chrome flags (chrome://flags), or for a shared deployment serve an Origin-Trial header from a fronting proxy.
The HTTP transport is stateless: it supports MCP protocol version 2026-07-28 (no
initialize handshake, no Mcp-Session-Id) while older clients (2024-11-05
through 2025-11-25) keep working through per-request sessions.
Start the server with HTTP transport:
3gpp-mcp serve --db data/3gpp.db --transport http --addr :8080Optionally enable Bearer token authentication:
export THREEGPP_MCP_BEARER_TOKEN=$(openssl rand -hex 32)
3gpp-mcp serve --db data/3gpp.db --transport http --addr :8080Then configure your client to connect via HTTP:
{
"mcpServers": {
"3gpp": {
"url": "http://your-server:8080",
"headers": {
"Authorization": "Bearer YOUR_SECRET_TOKEN"
}
}
}
}When using --web, the MCP endpoint moves to /mcp/.
See examples/systemd/ for production deployment with systemd.
The Dockerfile is multi-stage and builds the database for a release directly,
producing a self-contained image with the SQLite database (sections, OpenAPI
definitions, and embedded images) baked in. No pre-built database is needed in
the build context.
# Build an image with the latest version of every spec baked in (default)
docker build -t 3gpp-mcp:latest .
# ...or restrict the database to a single release
docker build --build-arg RELEASE=19 -t 3gpp-mcp:rel19 .
# ...or cap the newest release, keeping specs that have no version in it
docker build --build-arg MAX_RELEASE=19 -t 3gpp-mcp:max-rel19 .
# stdio transport (Claude Code / IDE integration)
docker run --rm -i 3gpp-mcp:latest
# HTTP transport
docker run --rm -p 8080:8080 3gpp-mcp:latest serve --db /3gpp.db --transport http --addr :8080RELEASE defaults to latest, which bakes in the latest version of every spec
across all releases. Set --build-arg RELEASE=<n> (e.g. 19) to restrict the
database to a single release, or --build-arg MAX_RELEASE=<n> to cap the newest
release without dropping specs that have no version in it. The two cannot be
combined.
To run on Cloud Run, see cloudbuild.yaml (build + push + deploy) and
service.yaml (Cloud Run service spec).
Every tool below also has a CLI twin (list_specs → 3gpp-mcp list-specs, and
so on) for shell use and scripting — see the
query commands in the Command Reference.
Tool | Description | Key Parameters |
| List available specifications (paginated) |
|
| List the versions of a spec and where each can be read from |
|
| Get table of contents of a spec |
|
| Get section content (paginated) |
|
| Compare two versions of a spec: structural summary, or a section text diff |
|
Every get_toc, get_section and search result names the specification and
version it came from, on every page of a paginated response.
The database holds one version per specification. To read another version, pass
version to get_section or get_toc. version accepts the dotted form
(15.8.0), the archive token (f80), a release selector (Rel-15 or 15,
picking the newest version in that release), or latest. Release selectors and
latest are resolved against the 3GPP archive, so they require on-demand
fetching (they do not work under --no-fetch). old_version and new_version
of compare_versions accept the same forms; new_version defaults to the
version in the database.
A version that is not in the database is downloaded from the 3GPP archive and
converted on first use. This takes up to a few minutes for a large
specification; if it is still running when the call's budget expires, the tool
says so and the same call repeated later returns the content. Results are kept
in a size-bounded cache (see serve) that is separate from the main
database, so:
search covers only the version in the database — cross-release full-text
search is not supported
get_references only has data for the version in the database, and a section
read from an archived version says so in its header
get_image and list_images accept a version too: an archived version's
images are downloaded on their own first use (one extra archive download per
version, with the same retry behavior), and EMF/WMF figures are converted to
PNG when LibreOffice is installed on the server
section numbers move between releases; check get_toc for the older version
before reading a section of it
Tool | Description | Key Parameters |
| Full-text search across all specs |
|
The search tool supports SQLite FTS5 query syntax:
Phrase search: "service based interface"
Boolean operators: AMF AND UE, AMF OR SMF, NOT deprecated
Exclusion after a positive term: handover -conditional
Prefix matching: handov*
Column filter: title:authentication, content:handover
Proximity: NEAR(AMF UE, 5)
Terms containing hyphens or dots (IMS-AKA, 38.101) are quoted automatically,
so they need no manual escaping.
Tool | Description | Key Parameters |
| Get cross-references between specs and RFCs |
|
Tool | Description | Key Parameters |
| List available OpenAPI definitions |
|
| Get OpenAPI definition (paginated) |
|
| Full-text search across OpenAPI definitions |
|
search_openapi uses its own FTS5 index, separate from the one search uses:
search covers specification clause text and never returns OpenAPI content,
search_openapi covers OpenAPI content only. One hit is one definition rather
than one document — a schema from components.schemas, or one HTTP method of
one path (named like PUT /nf-instances/{nfInstanceID}) — so you can find a
data type or an endpoint without knowing which API document defines it, then
read it in full with get_openapi. A query that is a single bare term ranks a
definition of exactly that name first, so NFProfile returns the NFProfile
schema ahead of the schemas that only reference it.
A schema's indexed text carries one level of $ref expansion — through items
and additionalProperties as well as directly, which is how the 5G SBI
definitions state most of their relationships — so the fields of a referenced
type are searchable from the schema that uses it; a type two hops away is not
in that text. Unlike search, this index applies no stemming
— identifiers are matched as written — and -, . and _ split tokens, so
Nnrf_NFManagement is also found by NFManagement and /nf-instances by
instances. camelCase is not split.
The index is built at the end of build and update. import and import-dir
leave it alone: the YAML files ship in the archive zip, so importing a .docx
cannot change what there is to index. A database built before this tool existed
has no index; add it in place with
build-openapi-index.
Tool | Description | Key Parameters |
| Get an ASN.1 assignment by name — in one spec or across all of them — or list a spec's assignment names |
|
The ASN.1-specified protocols (RRC TS 38.331/36.331, NGAP TS 38.413, S1AP
TS 36.413, XnAP, F1AP, ...) write their ASN.1 between -- ASN1START /
-- ASN1STOP markers, which the converter stores as ```asn1 fences (see
Code blocks). get_asn1 extracts every top-level assignment —
types, constants and information objects — from those fences.
With name it returns that assignment's full text together with the section
that defines it, so the answer can be cited. This matters for the protocols
that define all their IEs in one clause: NGAP's IE definitions clause is
hundreds of kilobytes, far more than one get_section page, while the one
definition that answers "what range does the ASN.1 allow here" is a few lines.
Matching ignores case and separators, so the IE table's AMF UE NGAP ID finds
the ASN.1's AMF-UE-NGAP-ID; a name that matches nothing gets similar names
suggested. A name defined more than once returns every definition, each under
its own source line.
When you do not know which specification defines a name, omit spec_id: the
name is resolved across every specification in the database, from a name
index built at database build time (build, update, import and
import-dir all refresh it). A lookup that names the wrong specification
gets told where the name is actually defined. A database built before this
tool existed has no index — add it in place with
build-asn1-index. Cross-spec resolution covers the
database versions only — pass spec_id (and optionally version) to read
an archived version, with the same on-demand download behavior as
get_section.
With a spec_id and no name it lists every assignment name, grouped by
defining section.
Tool | Description | Key Parameters |
| List embedded images in a spec |
|
| Get an embedded image as base64 data viewable by LLMs |
|
PNG/JPEG/GIF/WebP images are directly viewable by LLMs. EMF/WMF images (most 3GPP figures use this format) are stored as raw data by default; use --convert-image to convert them to PNG via LibreOffice at build time.
Figures are referenced from the section text in a single notation, whatever the
image format:  in body text and
<img src="image://NAME?w=&h=" ...> inside table cells. Pass that NAME to
get_image; both the original filename (image3.emf) and the converted one
(image3.png) resolve.
Section text carries tagged code fences, so both LLMs and the web viewer can tell the notations apart:
Fence | Content |
| ASN.1 modules between the |
| Diameter command and grouped-AVP definitions (RFC 6733 CCF) |
| XML schemas, XML body examples and DTDs |
| SIP/RTSP message examples |
| Standalone SDP session descriptions |
| Standalone equations converted from Word OMML |
| Anything else the source document styles as code |
Word formulas (OMML) are converted to LaTeX in three notations, so a formula is readable whether it stands alone or sits in a sentence:
Notation | Where |
| A paragraph whose only content is an equation. Its equation number is kept as |
| Display equations that cannot be a fenced block — inside a table cell or a list item. |
| A formula inside a sentence. |
3GPP prose encodes structure in indentation — nested requirement and
condition lists, multi-level definitions. A body paragraph's leading
whitespace is preserved as no-break spaces (U+00A0), one tab of the source
document becoming four: a literal tab or 4+ leading spaces would turn the
line into an indented code block in Markdown (inside which HTML like
<sub> is never interpreted), while no-break spaces keep the visual
nesting in any renderer and stay out of the way of full-text search.
Attaching the server does not by itself make a model consult it: given the choice, some models answer 3GPP questions from memory. In the benchmark, Claude Sonnet 5 skipped retrieval on 40% of TeleQnA questions and GPT 5.6 Luna on 60%, and on those questions the tools were worth nothing. One sentence in the client's system prompt removes that discretion. The measured wording:
Do not answer from memory. Search the specifications first and base your answer on the text you retrieve, even when you are confident you already know the answer.
That sentence took Luna's skip rate to zero and its gain from +5.9 to +12.0 points, moved nothing on a model that already searched every question, and is worth nothing without the tools attached — it forces retrieval rather than smuggling in an answer. Stronger house rules in the same spirit — base every answer about 3GPP on clause text retrieved through these tools, and cite the clause — are reasonable, but only the sentence above is what the benchmark measured.
For spot comparisons across releases, compare_versions and the version parameter need no extra setup. Building a separate database per release still pays off when you work against one release continuously: full-text search, get_references and OpenAPI definitions only cover the version baked into the database, so a release-specific database gives you all three for that release, with no on-demand downloads.
# Build databases for different releases
3gpp-mcp build --release 18 --db data/3gpp-rel18.db --convert-doc --convert-image
3gpp-mcp build --release 19 --db data/3gpp-rel19.db --convert-doc --convert-image--release keeps only specs that have a version in that exact release, so a
spec frozen in an earlier release (TS 34.108, for example) is missing from the
database entirely. To pin a release without losing those specs, cap the
selection instead — every spec is taken at its newest version at or below the
cap:
# Everything as of Release 19: specs with no Rel-19 version fall back to their
# newest older version rather than dropping out.
3gpp-mcp build --max-release 19 --db data/3gpp-rel19.db --convert-doc --convert-image
# Keep the cap when refreshing the database later.
3gpp-mcp update --max-release 19 --db data/3gpp-rel19.db --convert-docRegister them as separate MCP servers:
claude mcp add --scope user 3gpp-rel18 -- 3gpp-mcp serve --db /path/to/data/3gpp-rel18.db
claude mcp add --scope user 3gpp-rel19 -- 3gpp-mcp serve --db /path/to/data/3gpp-rel19.dbUse the update command to check for newer versions of specs already in your database:
3gpp-mcp update --db data/3gpp.db --convert-doc --convert-imageserveStart the MCP server.
Flag | Description | Default |
| Path to SQLite database |
|
| Transport type: |
|
| HTTP listen address (env: |
|
| Bearer token for HTTP auth (env: | |
| Enable web viewer alongside MCP server (HTTP transport only) |
|
| Disable on-demand fetching of spec versions that are not in the database |
|
| Path to the on-demand version cache |
|
| Size limit of the version cache in MB. |
|
| How long a tool call waits for an on-demand fetch before asking the caller to retry (env: |
|
The version cache is a separate SQLite file, so the main database stays
read-only and is never polluted with extra versions. When the cache cannot be
created — a read-only or ephemeral filesystem, such as the scratch-based
container image — the server logs a warning and runs with on-demand fetching
disabled; everything else keeps working. Cached versions are evicted
least-recently-used once the size limit is exceeded.
HTTP transport also exposes GET /health, which returns 200 OK without authentication. Use this path for platform health checks (Cloud Run, Sakura AppRun, Kubernetes liveness/readiness probes, etc.).
buildDownload and import specifications into the database (recommended for initial setup). Alias: pipeline.
Flag | Description | Default |
| Output SQLite database path |
|
| Process specs for a specific release (e.g. | |
| Cap the selection at a release (e.g. | |
| Select every spec at its latest version (use when no other selector is given) |
|
| Process a specific spec (e.g. | |
| Filter by series, comma-separated (e.g. | |
| Number of parallel workers | NumCPU |
| Convert |
|
| Convert EMF/WMF images to PNG using LibreOffice |
|
| Read the spec list from a file instead of scraping the archive (a selector is still required) | |
| Disable the spec list cache |
|
| Concurrency for scraping spec listings ( |
|
| HTTP timeout |
|
One of --release, --max-release, --latest, --series or --spec must be
given, --spec-list included: the file supplies the candidate entries and the
selector filters them.
--release and --max-release differ in what happens to a spec that has no
version in the named release: --release 19 drops it, --max-release 19 keeps
it at its newest version below the cap. They cannot be combined.
download — Download specifications without conversion (--output-dir, default specs). Requires one of --release, --max-release, --latest, --series or --spec, like build.
import — Import a single .docx file into the database. Alias: convert. Usage: 3gpp-mcp import --db data/3gpp.db path/to/spec.docx
import-dir — Import all .docx files in a directory into the database. Alias: convert-dir. Usage: 3gpp-mcp import-dir --db data/3gpp.db ./specs
update — Update specifications in the database to latest versions, or to a cap with --max-release.
build-openapi-index — Rebuild the OpenAPI search index of an existing database. build and update do this themselves, so it is for adding the index to a database built before search_openapi existed: serve opens the database read-only and cannot create it on the fly.
build-asn1-index — Rebuild the ASN.1 name index of an existing database. build, update, import and import-dir do this themselves, so it is for adding the index to a database built before get_asn1 existed.
completion — Print a shell completion script: 3gpp-mcp completion bash (or zsh, fish)
The cap is not stored in the database, so a database built with
--max-release 19 needs the same flag on update — otherwise the update
lifts every spec to the newest release on the archive. With a cap the update moves a spec
in either direction, so it also brings an already-built uncapped database down
to the cap; a spec whose every version is above the cap is removed, since no
version of it belongs in a capped database. A spec missing from the archive
listing is left untouched, as a failed listing looks the same as a withdrawn
spec.
The query commands (list-specs, list-versions, get-toc, get-section,
get-asn1, compare-versions, search, list-openapi, get-openapi,
search-openapi, get-references, list-images, get-image) mirror the MCP
read tools 1:1, so
the database can be inspected and scripted from a shell without an MCP client:
3gpp-mcp search --db data/3gpp.db --limit 3 "AMF AND authentication" | jq '.results[].section_number'
3gpp-mcp get-section --db data/3gpp.db "TS 23.501" 5.15.2 | lessConventions shared by all of them:
Flags must come before positional arguments.
JSON results print to stdout indented and unpaginated — pipe to jq,
head or less. Warnings and progress notes go to stderr, so stdout stays
parseable.
Commands that accept --version (and compare-versions) take the same
version forms as the MCP tools (15.8.0, f80, Rel-15, latest) and
wait for an on-demand download to finish instead of asking you to retry;
interrupt with Ctrl-C. They share serve's fetch flags: --no-fetch,
--version-cache, --version-cache-mb, --fetch-budget. Queries that name
no version never create the version cache (list-versions reads an existing
cache to report cached availability, but will not create one).
Every command takes --db (default 3gpp.db).
Variable | Description |
| Transport for |
| HTTP listen address for |
| Bearer token for HTTP transport auth |
| PaaS convention (Cloud Run / Heroku); |
| Size limit of the on-demand version cache in MB (default |
| How long a tool call waits for an on-demand fetch (default |
| Max ZIP download size (default |
| Spec list cache TTL in hours (default |
| Initial backoff between archive listing fetch attempts in ms (default |
| Cache directory root, per the XDG Base Directory spec |
Compare two versions of a 3GPP specification. Without section_number, returns a structural summary: sections added, removed, renumbered, retitled, and whose content changed. With section_number, returns a line-level unified diff of that section's text. Use list_versions first to see which versions exist; a version not yet cached is downloaded and converted on first use — when the tool says a download is in progress, call it again with the same arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Start line number (0-based, default: 0) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| max_chars | No | Maximum number of characters to return (can be combined with max_lines) | |
| max_lines | No | Maximum number of lines to return (default: 200) | |
| new_version | No | Newer version to compare to. Defaults to the version in the database. | |
| old_version | Yes | required,Older version to compare from (e.g. 17.9.0). Also accepts an archive token (h90) or a release selector (Rel-17). Use list_versions to see what exists. | |
| context_lines | No | Unchanged lines shown around each change in a section diff (default: 3) | |
| section_number | No | Compare only this section's text as a unified diff (e.g. 5.15.2). Omit for a structural summary of the whole specification. | |
| include_subsections | No | With section_number: include subsections in the diff (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It transparently discloses that uncached versions trigger a download that may require a second call. It also explains the two output modes. While it doesn't cover all potential edge cases (e.g., error handling), the key behavioral trait is well documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: four sentences covering two distinct modes, prerequisites, and first-use behavior. No redundant words. Information is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description is remarkably complete. It explains the two output modes, how to pick versions, and the caching behavior. The only minor gap is that it doesn't describe the format of the structural summary, but that's a niche detail. Overall, it provides sufficient context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description adds significant context beyond the schema: it explains how 'section_number' changes the output type (summary vs. diff), and gives concrete examples like '5.15.2'. The 'old_version' description also clarifies it accepts archive tokens and release selectors, which is not in the schema. This adds substantial semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Compare two versions of a 3GPP specification', clearly defining the verb and resource. It then distinguishes two modes: without section_number (structural summary) and with section_number (line-level diff). This differentiates it from sibling tools like 'get_section' or 'list_versions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each mode and directs to use 'list_versions first to see which versions exist'. It also explains behavior on first use (download/conversion) and instructs to retry if a download is in progress. This is clear guidance on usage vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ASN.1 definitions from the 3GPP specifications. The protocol specifications (RRC TS 38.331/36.331, NGAP TS 38.413, S1AP TS 36.413, XnAP, F1AP, LPP TS 37.355, ...) write their ASN.1 between -- ASN1START / -- ASN1STOP markers, and this tool extracts every top-level assignment from those blocks. With name, it returns the full text of that assignment — type, constant or information object — together with the specification and section that define it, so the answer can be cited. Use it when you know a type, IE or constant name and need its definition or constraints: the defining clause can be hundreds of kilobytes, which get_section can only page through. If you do not know which specification defines the name, omit spec_id — the name is resolved across every specification in the database. Matching ignores case and separators, so an IE table title like 'AMF UE NGAP ID' finds AMF-UE-NGAP-ID. With a spec_id and no name, it lists every assignment name grouped by the section that defines it. Pass version (with spec_id) to read a past version, which is downloaded and converted on first use; call list_versions first to see which versions exist.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ASN.1 assignment name (e.g. AMF-UE-NGAP-ID). Matching ignores case and separators, so an IE title like 'AMF UE NGAP ID' also resolves. Required when spec_id is omitted; with a spec_id, omit it to list every assignment name in the specification. | |
| offset | No | Start line number (0-based, default: 0) | |
| spec_id | No | Specification ID (e.g. TS 38.413). Omit it to look the name up across every specification in the database — use that when you do not know which specification defines the type. | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database, and requires spec_id. Use list_versions to see what exists. | |
| max_chars | No | Maximum number of characters to return (can be combined with max_lines) | |
| max_lines | No | Maximum number of lines to return (default: 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the scope of extraction (only top-level assignments from blocks between ASN1START/ASN1STOP markers), behavior with and without the name parameter, case-insensitive and separator-ignoring matching, and handling of past versions (downloaded and converted on first use). Since no annotations are provided, the description carries full burden, which it largely fulfills, though it could be more explicit about potential limitations (e.g., if the tool is destructive or read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise for the amount of information conveyed, but it is somewhat lengthy (multiple sentences). It is front-loaded with the core purpose, then progressively adds details on usage modes, matching behavior, and version handling. Every sentence adds value, but some redundancy could be trimmed (e.g., explaining matching behavior both in the main description and in the parameter description).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, multiple usage modes, no output schema), the description provides comprehensive guidance on how the tool behaves in different scenarios (with/without name, with/without spec_id, with version). It also addresses how to cite results and how to discover versions. The only gap is the lack of information about the return format or output structure, but since there is no output schema, the description could be more explicit about what the tool returns (e.g., structured text, markdown, etc.).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds extra context beyond the schema, such as the effect of omitting spec_id to search across all specs, the matching behavior (case-insensitive, separator-ignoring), and the fact that name is required when spec_id is omitted. It also explains the version parameter behavior and recommends list_versions. However, since schema coverage is complete, the description exceeds the baseline of 3 but does not substantially add new meaning for every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts ASN.1 definitions from 3GPP specifications, specifying verb ('Get', 'extracts') and resource ('ASN.1 definitions from the 3GPP specifications'). It distinguishes it from siblings like get_section by explaining that the defining clause can be hundreds of kilobytes, which get_section can only page through.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (e.g., 'Use it when you know a type, IE or constant name and need its definition or constraints') and when to use alternatives (e.g., 'the defining clause can be hundreds of kilobytes, which get_section can only page through'). It also provides guidance on omitting spec_id when the specification is unknown, and directs users to call list_versions first to see available versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an embedded image from a 3GPP specification. Returns the image as base64-encoded data that can be directly viewed by the LLM. Use list_images to discover available images for a spec. Pass version to read a past version's image; the images of an archived version are downloaded on first use, which takes up to a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | required,Image filename (e.g. image1.png) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it states the output is base64-encoded, mentions a latency caveat for archived versions ('up to a few minutes'), and explains the default version behavior. This fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and output, and each sentence adds unique value. Could be slightly more concise by combining the first two sentences, but no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, the description covers tool purpose, input semantics, latency behavior, and next steps via sibling links. It does not mention what happens if parameters are invalid or if an image doesn't exist, but the overall completeness is high for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already explains each parameter well. The description adds value by clarifying `version` accepts both version strings and archive tokens, and defaults to the database version, which goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Get an embedded image') and resource ('3GPP specification'), and clearly distinguishes this tool from siblings like `list_images` by stating its function and output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly points to `list_images` for discovering available images and `list_versions` for version discovery, providing clear guidance on when to use alternative tools. However, it does not mention when not to use this tool (e.g., for non-image content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenAPI definition content for 5G service-based interface APIs (TS 29.xxx series). Use this tool to look up HTTP request/response details, API paths, parameters, request bodies, response schemas, and data type definitions. Use the path parameter to filter by API endpoint (e.g. /nf-instances) or the schema parameter to filter by data type (e.g. NFProfile). Use list_openapi first to discover available API names.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Filter by API path (e.g. /nf-instances) | |
| offset | No | Start line number for pagination (0-based, default: 0) | |
| schema | No | Filter by schema name (e.g. NFProfile) | |
| spec_id | Yes | required,Specification ID (e.g. TS 29.510) | |
| api_name | Yes | required,API name (e.g. Nnrf_NFManagement) | |
| max_lines | No | Maximum lines to return (default: 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as a 'get' and 'look up' operation, implying it is read-only and non-destructive. However, it does not explicitly state that it is safe, nor does it mention pagination behavior (offset, max_lines) or what happens in edge cases like no results. The description is adequate but lacks explicit behavioral details beyond the verb choice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the purpose in the first sentence and then elaborating on capabilities and usage. Every sentence contributes meaningful information without redundancy or fluff. It is compact and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description should provide a thorough understanding of the tool. It covers the main purpose, prerequisite workflow, and parameter usage, but it does not describe the output format (e.g., JSON/YAML), the meaning of offset and max_lines for pagination, or error handling. This leaves gaps in what a user can expect from the tool's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by providing concrete examples for the path parameter ('/nf-instances') and schema parameter ('NFProfile'), and by explaining the intended workflow for spec_id and api_name (use list_openapi to discover). This goes beyond the schema's structural descriptions, though it does not cover offset or max_lines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get OpenAPI definition content for 5G service-based interface APIs (TS 29.xxx series).' It distinguishes from siblings like list_openapi by specifying that it retrieves actual definition content, not just listing available APIs. The mention of looking up HTTP request/response details, paths, and schemas further clarifies the specific resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Use list_openapi first to discover available API names,' providing a clear prerequisite and directing to an alternative tool. It also gives specific usage guidance for parameters: 'Use the path parameter to filter by API endpoint (e.g. /nf-instances) or the schema parameter to filter by data type (e.g. NFProfile).' This tells the user exactly when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cross-references between 3GPP specifications and RFCs.
Directions:
outgoing (default): Find all specs/RFCs referenced by a given section. Requires spec_id and section_number. Use include_subsections to also gather refs from child sections.
incoming: Find all sections that reference a given spec (and optionally a specific section). Requires spec_id. section_number is optional.
Returns structured reference data including target spec, section, title (if available in DB), and context snippet. Responses are capped at 500 references; a separate notice reports the total, and offset pages through the rest.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of references to skip, for paging past a truncated response (default: 0) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| direction | No | outgoing (default): references FROM this section to other specs. incoming: references TO this spec/section from other specs. | |
| section_number | No | Section number (e.g. 5.1.2). Required for outgoing direction. | |
| include_subsections | No | Include subsections when collecting outgoing references (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral disclosure. It reveals the 500-reference cap, pagination via offset, and that responses include structured data plus a total-count notice. It does not mention rate limits or authorization, but those are not critical for a read-only lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for each direction, uses bullet-style formatting for readability, and every sentence adds essential guidance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, two modes), the description covers all necessary details: parameter requirements per mode, default behaviors, response structure, pagination limit, and output format. Without an output schema, it still describes the return data adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description adds semantic value beyond the schema by explaining parameter roles in context (e.g., section_number is required for outgoing, optional for incoming) and linking params to use cases (include_subsections only relevant for outgoing).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding cross-references between 3GPP specs and RFCs. It distinguishes two modes (outgoing and incoming) with specific resource targets (specs, RFCs, sections), and the sibling context shows no other tool overlaps with this function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use outgoing vs incoming direction, lists required vs optional parameters for each, and notes a default behavior ('outgoing (default)'). It also mentions a cap of 500 references with pagination, guiding the agent on handling large result sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the markdown content of a specific section in a 3GPP specification. This tool is for reading specification document text (architecture, procedures, requirements). For API details such as HTTP request/response bodies, paths, and data models of 5G service-based interfaces (TS 29.xxx series), use get_openapi instead. Specify the section number with the section_number parameter (e.g. 5.1.2). Figures appear as  links; fetch one with get_image and that NAME. Formulas are LaTeX: a standalone equation is a ```latex code block (its equation number kept as \tag{7.3-1}), and a formula inside a sentence or a table cell is delimited with $...$, or $$...$$ when the source sets it as a display equation. Pass version to read a past version, which is downloaded and converted on first use; call list_versions first to see which versions exist. Large sections are paginated (default 200 lines). Use offset and max_lines to navigate.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Start line number (0-based, default: 0) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. | |
| max_chars | No | Maximum number of characters to return (can be combined with max_lines) | |
| max_lines | No | Maximum number of lines to return (default: 200) | |
| section_number | Yes | required,Section number to retrieve (e.g. 5.1.2) | |
| include_subsections | No | Include all subsections (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It transparently explains how figures appear as `` links and how to fetch them with `get_image`, details LaTeX formula formatting (standalone vs. inline), describes version handling (first-use download/conversion), and reveals pagination behavior (default 200 lines). It does not cover error cases or what happens for invalid sections, but the behavioral disclosure is rich and helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of ~150 words, dense but well-organized. It front-loads the core purpose and sibling distinction, then covers output format, version handling, and pagination. While it could benefit from bullet points or more whitespace for scanning, every sentence adds value and there is no repetition. It is concise for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 2 required, no output schema, and no annotations, the description covers purpose, usage alternatives, output format (figures, formulas), version behavior, and pagination. It does not describe error handling (e.g., invalid section/spec) or the exact structure of the return value, but it provides enough context for an agent to use the tool effectively in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 7 parameters have descriptions), so baseline is 3. The description adds extra meaning beyond the schema: e.g., for `section_number` it gives an example ('5.1.2'), for `version` it explains the first-use download behavior, and for `offset`/`max_lines` it contextualizes pagination. This additional context improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the markdown content of a specific section in a 3GPP specification.' It also specifies the type of content (architecture, procedures, requirements) and explicitly distinguishes from the sibling tool `get_openapi` for API details. The verb 'get' and resource 'section' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct guidance on when to use this tool vs. `get_openapi` for API details. It advises to call `list_versions` first to check available versions and explains pagination with offset and max_lines. This explicit context helps the agent choose the correct tool and navigate parameters effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the table of contents (section structure) of a 3GPP specification. Pass version to see the structure of a past version, which is downloaded and converted on first use; section numbers often move between releases, so check the table of contents before reading a section of an older version.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals that passing a 'version' triggers a download and conversion on first use, and notes that section numbers often change between releases. These are important behavioral traits. However, it does not state whether the operation is read-only or whether it has any side effects beyond the initial conversion (e.g., caching behavior). The transparency is good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. The first sentence defines the core purpose, and the second sentence adds targeted usage guidance and a behavioral note. Every sentence serves a clear function, and the structure is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is nearly complete. It explains what the tool does, the version behavior, and a typical use case. It could be improved by briefly describing the return format (e.g., list of section numbers and titles), but the phrase 'section structure' provides enough context for an agent to infer the output. The absence of an output schema increases the value of a description, and this one is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds minimal parameter-specific meaning beyond what the schema already provides. It mentions the 'version' parameter's purpose ('see the structure of a past version') and the conversion note, but the schema already describes the parameter's accepted formats and defaults. The description does not enrich the semantics of 'spec_id' beyond what is obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('table of contents (section structure) of a 3GPP specification'). It distinguishes the purpose from siblings like 'get_section' (which reads a specific section) and 'list_versions' (which lists versions). The phrase 'check the table of contents before reading a section' further clarifies its role relative to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use this tool to inspect the section structure, especially before reading an older version. It warns that section numbers move between releases, implying when to use this tool over others. While it does not explicitly name alternative tools (e.g., 'get_section'), the guidance is direct and actionable. The version parameter description (in schema) adds additional hints like using 'list_versions', which compensates slightly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List embedded images in a 3GPP specification. Returns image names, MIME types, and whether they are viewable by LLMs. Use get_image to retrieve a specific image. Pass version to list a past version's images; the images of an archived version are downloaded on first use, which takes up to a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits such as the latency for archived versions ('takes up to a few minutes') and the defaulting behavior of the version parameter. No annotations are provided, so the description carries the full burden and does so effectively, though it could mention if the list is paginated or has size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and well-structured, with the main action upfront, followed by sibling tool reference, and version handling details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters with full schema descriptions and no output schema, the description covers usage context well. It explains the version parameter's behavior and an edge case (archived version latency). A minor gap is not stating whether the returned list is complete or paginated, but overall it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters, so the baseline is 3. The description adds useful context for the 'version' parameter (e.g., about archive tokens and release selectors) beyond the schema's brief note, but does not add new info for 'spec_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List embedded images in a 3GPP specification') and specifies what it returns ('image names, MIME types, and whether they are viewable by LLMs'). It distinguishes itself from sibling tools like 'get_image' by noting that 'list_images' lists images while 'get_image' retrieves a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool vs alternatives: 'Use get_image to retrieve a specific image.' It also explains how to handle versions, including past archived versions that may have a delay. However, it does not explicitly mention when not to use it or other exclusions beyond the sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available OpenAPI definitions from 3GPP specifications (TS 29.xxx series). Use this to discover API names before calling get_openapi. Optionally filter by spec ID.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | No | Filter by specification ID (e.g. TS 29.510) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the basic action (listing definitions) and optional filtering, but does not disclose any behavioral traits such as return format, pagination, authentication requirements, or performance implications. For a simple read-only list tool, this is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence defines the action and resource; the second provides usage context and an optional filter. Every phrase earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description is mostly complete. It links usage to get_openapi and mentions filtering. However, it does not explain the return data shape (e.g., list of API names) or differentiate from other sibling tools like list_specs or search_openapi. Slight room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single parameter spec_id has a schema description). The description adds 'Optionally filter by spec ID,' which mirrors the schema. Since the schema already documents the parameter fully, the description adds minimal extra meaning, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List available OpenAPI definitions from 3GPP specifications (TS 29.xxx series).' It uses a specific verb ('list') and resource ('OpenAPI definitions'), and distinguishes from siblings like get_openapi (which gets a specific definition) and list_specs (which lists specs). The context 'discover API names before calling get_openapi' further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use this to discover API names before calling get_openapi.' It also mentions optional filtering by spec ID. While it does not explicitly state when not to use it or list alternatives (e.g., list_specs), the guidance is clear and contextually useful for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available 3GPP specifications. Optionally filter by series number and/or by an ID prefix (query). Results are paginated (default 20 per page); use limit and offset to navigate.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 20) | |
| query | No | Filter specs whose ID starts with this text (e.g. '38.21' matches 38.211, 38.212, 38.213) | |
| offset | No | Number of results to skip for pagination (default: 0) | |
| series | No | Filter by series number (e.g. 23 for TS 23.xxx) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It adds pagination defaults and filter semantics beyond the schema, but does not mention authentication needs, output format, error behavior, or rate limits—leaving significant gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second covers filtering and pagination. No wordiness, front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 4 optional parameters and no output schema, the description explains filters and pagination adequately but omits what the response looks like (e.g., fields returned, ordering). Without output schema, the description should hint at the return structure to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context that filters can be combined and how pagination works (limit/offset navigation), but most parameter meaning is already clear from schema descriptions. The added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb "List" and the resource "available 3GPP specifications." It mentions optional filtering by series and ID prefix, plus pagination—fully distinguishing this from sibling tools that list images, OpenAPI specs, or versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains optional filtering and pagination, so the agent knows how to use it. However, it does not provide any guidance on when NOT to use this tool vs. alternatives (e.g., search, get_section), missing the opportunity to prevent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the versions of a 3GPP specification, newest first.
Each entry reports where the version can be read from:
database: in the prebuilt database, covered by search, images and cross-references
cached: fetched on demand earlier, available immediately
archive: exists upstream; reading it downloads and converts it first, which takes up to a few minutes for a large specification
Pass a version from this list to get_section or get_toc to read a past version.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses behavioral traits: newest-first order, the meaning of three statuses (database, cached, archive), and time cost for archive versions. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, bulleted details, and a usage recommendation. It is concise with no redundant information, though slightly more compacting is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the output (list of versions with status meanings) and connects to sibling tools, making the tool's usage context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no meaning beyond the schema's own parameter description ('Specification ID (e.g. TS 23.501)'). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List the versions of a 3GPP specification, newest first' – a specific verb and resource that clearly distinguishes from sibling tools like list_specs (list specifications) and list_images (list images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for use: 'Pass a version from this list to get_section or get_toc to read a past version.' This guides when to use the tool, but does not explicitly exclude scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across 3GPP specifications using SQLite FTS5 syntax.
Query syntax:
AND/OR/NOT: AMF AND authentication
Phrase: "service based interface"
Prefix: handov*
Column filter: title:authentication or content:handover
Proximity: NEAR(AMF UE, 5)
Hyphenated or dotted terms (e.g. IMS-AKA, sec-agree, 38.101) are auto-quoted to avoid FTS5 syntax errors.
After a positive term, "-term" excludes that term (e.g. AMF -SMF), same as NOT. An exclusion cannot begin a query or immediately follow AND/OR.
Stemming:
The index uses porter stemming: inflected English forms match each other (handover finds handovers).
Prefix and phrase queries operate on stemmed forms, so they can match a bit more broadly than the exact surface text.
Pagination:
Results come as {results, total_count, limit, offset}; total_count is the full match count.
Use limit (default 10, max 200) and offset to page through matches beyond the first page.
Tips:
Use exact 3GPP terms (AMF, SMF, gNB, UE, NRF, PCF, etc.)
Phrase search improves precision for multi-word concepts
title:term restricts matches to section headings only
Use spec_ids to search across multiple specifications at once
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results per page (default: 10, max: 200) | |
| query | Yes | required,FTS5 query string. Hyphenated or dotted terms like IMS-AKA and 38.101 are auto-quoted. Use AND/OR/NOT operators and double-quoted phrases for exact matches (e.g. '"core network" AND AMF'). | |
| offset | No | Number of results to skip for pagination (default: 0). Combine with total_count in the response to page through all matches. | |
| spec_id | No | Limit search to a single specification (e.g. TS 23.501). Ignored when spec_ids is provided. | |
| spec_ids | No | Limit search to one or more specifications (e.g. ["TS 23.501", "TS 23.502"]). Takes precedence over spec_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given there are no annotations, the description carries full burden for behavioral disclosure. It explicitly states key behaviors: auto-quoting of hyphenated/dotted terms, exclusion syntax, porter stemming, pagination with total_count, and the precedence of spec_ids over spec_id. This is comprehensive beyond what the schema reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (Query syntax, Stemming, Pagination, Tips) and is well organized. It earns its length given the complexity of FTS5 syntax, but could be slightly more concise in the exclusion rules section, which repeats some details from the syntax list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers query syntax, stemming, pagination, and provides domain tips. There is no output schema, but the response structure is described inline (results, total_count, limit, offset). The description is complete for a search tool of this complexity. Minor gap: it does not explain what happens on an empty query or FTS5 syntax errors beyond auto-quoting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does add value for some parameters (e.g., explaining spec_ids precedence over spec_id, and specifying default/max for limit), but mostly the query syntax details are an extension of the 'query' parameter's natural behavior rather than new parameter-specific semantics. The description does not add meaning significantly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb and resource: 'Full-text search across 3GPP specifications'. It specifies the technology (SQLite FTS5 syntax), and the query examples clearly differentiate it from sibling tools like search_openapi or list_specs. The purpose is specific and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive query syntax and tips for effective search (tips on exact terms, phrase search, column filters), but it does not explicitly state when to use this tool versus alternatives like search_openapi or get_section. There is no 'when-not-to-use' guidance. Usage is implied through examples and tips but not formally defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across the OpenAPI definitions of the 5G service-based interface APIs (TS 29.xxx series), using SQLite FTS5 syntax.
Use this when you need an API detail but do not know which API document holds it — searching for a data type (NFProfile, SmContextCreateData) or an endpoint (/nf-instances, subscriptions) finds it without guessing an api_name first. When you already know the document, get_openapi reads it directly.
This is a separate index from the search tool: search covers specification clause text and never returns OpenAPI content, and this tool covers OpenAPI content only.
Results:
One hit is one definition, not one document: either a schema (a data type from components.schemas) or an operation (one HTTP method of one path, named like "PUT /nf-instances/{nfInstanceID}").
A query that is a single bare term ranks a definition of exactly that name first, so searching NFProfile returns the NFProfile schema itself ahead of the schemas that merely reference it.
Each hit reports spec_id, api_name, kind, name and a snippet. Pass those to get_openapi (with its schema or path parameter) to read the full definition.
A schema's text carries one level of $ref expansion, so referenced field names are searchable, but a type two hops away is not. Follow it up with get_openapi.
Set include_body to get the matched definition's full text inline. It is much larger than a snippet.
Query syntax:
AND/OR/NOT: NFProfile AND heartbeat
Phrase: "nf instances"
Prefix: subscri*
Column filter: name:NFProfile or body:nfInstanceId or api_name:Nnrf_NFManagement
Hyphenated, dotted or underscored terms (e.g. nf-instances, 29.510, Nnrf_NFManagement) are auto-quoted to avoid FTS5 syntax errors.
Tokenization:
Unlike search, this index applies no stemming: identifiers are matched as written, and inflected English forms do not fold together.
'-', '.' and '_' split tokens, so Nnrf_NFManagement is indexed as "nnrf" and "nfmanagement" and /nf-instances as "nf" and "instances" — a partial name matches, but camelCase is not split (supportedFeatures is one token).
Pagination:
Results come as {results, total_count, limit, offset}; total_count is the full match count.
Use limit (default 10, max 200) and offset to page through matches beyond the first page.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Limit the search to one kind of definition: "schema" for data types or "operation" for endpoints. Both are searched when omitted. | |
| limit | No | Maximum number of results per page (default: 10, max: 200) | |
| query | Yes | required,FTS5 query string. Hyphenated or dotted terms like nf-instances and 29.510 are auto-quoted. Use AND/OR/NOT operators and double-quoted phrases for exact matches. | |
| offset | No | Number of results to skip for pagination (default: 0). Combine with total_count in the response to page through all matches. | |
| api_name | No | Limit the search to a single API document (e.g. Nnrf_NFManagement). Use list_openapi to see the available names. | |
| spec_ids | No | Limit the search to one or more specifications (e.g. ["TS 29.510", "TS 29.518"]). | |
| include_body | No | Return the full text of each matching definition instead of a snippet (default: false). Costs many more tokens; prefer the default and follow up with get_openapi. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It comprehensively discloses behavior: result granularity (one definition per hit), ranking (exact name matches first), $ref expansion depth, include_body effect, query syntax (including auto-quoting for special characters), tokenization rules (no stemming, split on hyphens/dots/underscores, no camelCase split), and pagination details. No contradictory or missing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Results, Query syntax, Tokenization, Pagination) and front-loaded with the main purpose. While it is long, every sentence provides necessary information given the tool's complexity. It could be slightly more concise, but it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, multiple sibling tools), the description is complete. It explains the result structure, how to follow up with get_openapi, the difference from search, tokenization idiosyncrasies, and pagination. It addresses all likely agent questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds substantial value beyond the schema. It explains the query syntax in detail (operators, phrases, column filters, auto-quoting), the purpose and cost of include_body, how pagination uses limit/offset with total_count, and the meaning of kind (schema vs operation). The description makes the parameters much more usable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool performs full-text search on OpenAPI definitions of 5G APIs, using SQLite FTS5 syntax. It distinguishes from sibling tools by explicitly contrasting with 'search' (covers clause text, not OpenAPI) and 'get_openapi' (for when the document is already known).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this when you need an API detail but do not know which API document holds it.' It also gives a clear alternative: 'When you already know the document, get_openapi reads it directly.' Additionally, it contrasts with the sibling 'search' tool, specifying that search covers different content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0compare_versionsget_asn1get_imageget_openapiget_referencesget_sectionget_toclist_imageslist_openapilist_specslist_versionssearchsearch_openapiEvery tool targets a distinct content type or operation: listing vs. retrieval, specification text vs. ASN.1 vs. OpenAPI vs. images vs. cross-references. The two search tools explicitly separate specification clauses from OpenAPI definitions, eliminating ambiguity.
All tools use a consistent lowercase snake_case convention with a verb-noun pattern (list_*, get_*, search_*, compare_versions). No mixed conventions or irregular names, making it easy to infer functionality from the name.
13 tools is a well-scoped set for a specification retrieval system. Each tool adds a distinct capability—discovery, reading, searching, comparison, images, ASN.1, OpenAPI, references—without redundancy or bloat.
The tool surface covers the full lifecycle of read-only specification access: discovery (list_specs, list_versions, list_openapi, list_images), retrieval (get_section, get_image, get_asn1, get_openapi), searching (search, search_openapi), comparison (compare_versions), and cross-references (get_references). No obvious gaps for the stated domain.
Hosted 3GPP MCP server for Rel-15–20 TS/TR search. Index stays current.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/higebu/3gpp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
