This server provides tools to search, navigate, and extract content from 3GPP and IETF RFC specifications.
Search 3GPP documents (search_3gpp_docs): Keyword-based search across specs (e.g., TS 24.008, TS 24.301, TS 24.501, TS 36.300), with optional filtering by spec name and configurable result limits.
Get EMM/5GMM cause codes (get_emm_cause): Look up detailed info (number, name, description, source spec) for EMM (LTE) or 5GMM (5G) cause codes by cause number.
List available specifications (list_specs): Get all indexed 3GPP specs with total indexed chunk counts.
Detailed spec catalog (get_spec_catalog): Access a comprehensive catalog including titles, versions, series, descriptions, and content statistics.
Navigate chapter hierarchy (get_spec_toc): Retrieve the Table of Contents for a specification, with optional depth or section prefix limits.
Retrieve exact section text (get_section): Fetch precise text for a section using its unique ID or a spec ID + section number combination.
Expand related sections (search_related_sections): Discover sections related to an anchor section — parents, children, siblings, and neighbors.
Trace cross-spec references (get_spec_references): Explore incoming and outgoing citations between different specifications.
Access ingestion guidelines: Retrieve operational instructions for tasks like ETSI download, RFC ingestion, or managing the extraction pipeline.
Provides query expansion for semantic search using NVIDIA NIM API to generate hypothetical 3GPP-style answers, bridging vocabulary gap between queries and documents.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-3gpp Explain 5GMM cause 27 from TS 24.501"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for 3GPP and IETF RFC specifications, backed by a prebuilt SQLite corpus.
The current v2 server is built around AI-guided chapter navigation, not hard-coded protocol lookup logic. The intended workflow is:
Discover relevant specs with get_spec_catalog, search_etsi_catalog, or search_3gpp_docs.
Walk the chapter structure with get_spec_toc.
Retrieve exact text with get_section.
Expand locally with search_related_sections.
Jump across documents with get_spec_references.
Extract test case structure with get_test_case_structure and list_test_cases.
Search is a starting point, not the whole product. The model is expected to browse and choose chapters deliberately.
DB-backed v2 server with 12 MCP tools
Prebuilt corpus in data/corpus/3gpp.db
207 specs total: 113 TS, 1 TR, 93 RFC
66,109 full sections and 63,376 TOC rows
45,162 cross-spec reference edges
Stdio MCP entrypoint in src/index.js
Optional Streamable HTTP transport in src/http.js
Hybrid search with 4-way RRF (Reciprocal Rank Fusion)
Optional AnyTXT Searcher integration for Windows
Optional HyDE (Hypothetical Document Embeddings) query expansion via NVIDIA NIM API
Related MCP server: IEEE 802.11 MCP Server
Search uses a multi-stage retrieval pipeline with up to four parallel retrievers fused by RRF (Reciprocal Rank Fusion, k=60):
Query -> [FTS5/BM25] (keyword, always active)
-> [sqlite-vec] (semantic, when embeddings ready)
-> [AnyTXT API] (full-document, when AnyTXT running on Windows)
-> [HyDE + LLM] (query expansion, when NVIDIA API key configured)
-> RRF fusion -> Structure-aware ranking -> ResultsKey properties:
Baseline npm install gives you the keyword-ready server path: BM25/FTS search, TOC navigation, exact section retrieval, and cross-spec references.
search_3gpp_docs supports quoted phrases, spec: filters, section: hints, and negation in that baseline path.
RRF fusion replaces raw score combination with rank-based scoring, eliminating the need for score normalization across retrievers with incompatible distributions. Use fusion: 'rrf' (default) or fusion: 'linear' to switch.
The database and runtime can host sqlite-vec embeddings via vec_sections, but that only makes the corpus vector-capable.
Semantic or hybrid retrieval should be treated as an optional readiness state. It is active only when the runtime has semantic prerequisites and the smoke path actually returns mode_actual=hybrid or mode_actual=semantic with semantic evidence in results.
HyDE expands short/vague queries by generating a hypothetical 3GPP-style answer via NVIDIA LLM, then embedding that answer for vector search. This bridges the vocabulary gap between queries and documents.
Node.js 20.x, 22.x, and 24.x are the supported, CI-tested runtimes.
The project uses better-sqlite3 12.x so installs can use prebuilt native binaries across the supported Node versions, including Node 24 on Windows.
If you expand the Node version range later, update the native dependency and CI matrix together.
git lfs install
git clone https://github.com/Lee-SiHyeon/mcp-server-3gpp.git
cd mcp-server-3gpp
npm install
npm run validate
npm startThe bundled database is tracked with Git LFS. A healthy startup looks like:
[3GPP MCP] Database ready: .../data/corpus/3gpp.db
[3GPP MCP] Features - FTS: true, Vector: true
[3GPP MCP] Registered 12 tools (v2 DB mode)npm run validate now reports two separate states:
Baseline keyword readiness: the DB-backed 12-tool server is healthy and search/navigation work in keyword mode.
Optional semantic readiness: whether semantic prerequisites are installed and whether the live tool smoke test actually activated semantic/hybrid retrieval.
{
"mcpServers": {
"3gpp": {
"command": "node",
"args": ["/absolute/path/to/mcp-server-3gpp/src/index.js"]
}
}
}{
"servers": {
"3gpp": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/mcp-server-3gpp/src/index.js"]
}
}
}{
"env": {
"THREEGPP_DB_PATH": "/custom/path/to/3gpp.db"
}
}The server checks these DB locations in order:
THREEGPP_DB_PATH
data/corpus/3gpp.db
data/3gpp.db
Tool | Purpose |
| List indexed specs with title, version, series, description, section count, and page count. |
| Return the chapter hierarchy for a spec, optionally limited by depth or section prefix. |
| Fetch the exact section text by |
| Rank candidate sections for a query and return section IDs for follow-up retrieval. |
| Expand from an anchor section through parent, child, sibling, and search-derived neighbors. |
| Traverse incoming and outgoing cross-spec citations. |
| Search cataloged ETSI delivery metadata, including documents not yet downloaded or embedded. |
| Inspect one ETSI catalog document with versions and optional file URLs. |
| Return operational instructions for ETSI download, RFC ingest, or the extraction pipeline. |
| Compatibility alias with a smaller output shape; prefer |
| Extract structured test case data (Test Purpose, Conformance Requirements, Test Procedure) from conformance specs. |
| List all test case sections within a spec. |
Use prompts that encourage structure-first navigation:
Find the chapter in TS 24.301 that defines attach reject causes.
Start by locating the spec, then inspect the TOC, then fetch the most relevant section.I need the exact wording for the NAS registration timer behavior in 5G.
Search for likely sections, then read the chapter text and nearby sections.Show which RFCs and 3GPP specs TS 29.500 cites most often.Metric | Value |
Total specs | 207 |
TS specs | 113 |
TR specs | 1 |
RFC specs | 93 |
TOC rows | 63,376 |
Section rows | 66,109 |
Cross-spec references | 45,162 |
Ingestion runs recorded | 535 |
LLM client
-> MCP transport (stdio or HTTP)
-> tool registry + validation
-> tool handlers
-> SQLite corpus (specs, toc, sections, sections_fts, spec_references, ingestion_runs)
-> ETSI catalog (etsi_publication_types, etsi_ranges, etsi_documents, etsi_versions, etsi_files)
-> optional vec_sections table and guide resources
-> search pipeline:
keywordSearch.js (FTS5 + BM25)
semanticSearch.js (sqlite-vec cosine)
anytxtSearch.js (AnyTXT JSON-RPC API, Windows only)
hydeExpander.js (NVIDIA NIM LLM for query expansion)
hybridRanker.js (RRF fusion + structure-aware ranking)More detail lives in docs/architecture.md and docs/data-model.md.
npm run validate
npm testnpm run validate checks the package metadata, resolves the DB path, verifies the core schema and counts, confirms the v2 12-tool surface, runs the navigation smoke path, and reports semantic readiness separately from baseline keyword readiness.
Semantic retrieval is not part of the baseline install contract. Treat it as an operator opt-in layer on top of the keyword server.
Current prerequisites:
sqlite-vec must load successfully at runtime.
vec_sections must be populated with embeddings for the active corpus.
A compatible transformers runtime must be present for local embeddings. The repository now ships with @huggingface/transformers, and the runtime still accepts @xenova/transformers for compatibility.
The live search_3gpp_docs smoke path must actually return mode_actual=hybrid or mode_actual=semantic.
scripts/generate_embeddings.js is now the real local corpus-population workflow for vec_sections. It can build or rebuild the embedding index, but semantic-active readiness still requires a fresh full-corpus index. Partial runs (--spec or --limit) are useful for smoke tests and controlled backfills, but they intentionally do not mark semantic retrieval as globally ready.
ETSI catalog smoke:
npm run catalog:smokeThis crawls a tiny ETSI TS range into the catalog tables only. It does not
download PDFs, extract text, or generate embeddings. For broader cataloging,
use npm run catalog:crawl -- --all-publication-types --depth versions and add
limits such as --max-ranges, --max-docs, --max-versions, or
--max-requests for controlled backfills.
Catalog crawler safety controls:
python3 scripts/crawl_etsi_catalog.py --publication-types etsi_ts etsi_tr --depth documents --plan-only
python3 scripts/crawl_etsi_catalog.py --publication-types etsi_ts etsi_tr --depth documents --max-ranges 10
python3 scripts/crawl_etsi_catalog.py --publication-types etsi_ts etsi_tr --depth documents --resume
python3 scripts/select_etsi_ingest.py --policy priority --format download-listThe crawler records progress in catalog_crawl_runs and
catalog_crawl_progress. Long catalog writes remain CLI-only; MCP catalog tools
are read-only. Download, extraction, and embedding status lives separately from
document identity in etsi_document_status. select_etsi_ingest.py marks
priority 3GPP-mapped ETSI documents for later download/extract/embed work and
can emit a tab-separated download plan without downloading any PDFs.
Degraded-path smoke:
npm install
npm run validateExpected result:
Baseline keyword readiness: true
Optional semantic prerequisites met: false or Semantic-active tool smoke: false
Search mode actual: keyword
Semantic-active smoke:
Run npm install.
Ensure sqlite-vec loads and vec_sections is populated with a fresh full-corpus embedding index that matches the active 384-dim model/prefix contract. Example:
node scripts/generate_embeddings.js --rebuildRun npm run validate.
Expected result:
Optional semantic prerequisites met: true
Semantic-active tool smoke: true
Semantic smoke mode actual: hybrid or semantic
AnyTXT Searcher provides an additional search signal and document parsing for formats beyond PDF. When running, its JSON-RPC API at localhost:9920 is auto-detected.
Prerequisites:
Install AnyTXT Searcher on Windows.
Enable the HTTP API: menu Help -> API.
Sync the raw/ directory into AnyTXT's index (Tools -> Index Manager).
When available, AnyTXT adds a third retriever to the RRF fusion, searching raw file content including DOCX, XLSX, and scanned PDF (OCR). When unavailable, the pipeline degrades to 2-way RRF (keyword + semantic).
CLI extraction tool:
node scripts/extract_anytxt.js --check # verify API availability
node scripts/extract_anytxt.js --sync raw/ # sync raw dir to AnyTXT index
node scripts/extract_anytxt.js raw/ts_38_523_1.pdf # extract text from a file
node scripts/extract_anytxt.js --batch raw/ # batch extract all supported filesHyDE (Hypothetical Document Embeddings) improves recall for short or vague queries by generating a hypothetical 3GPP-style answer via LLM, then using that answer's embedding for vector search. This bridges the vocabulary gap between queries and technical documents.
Configure via environment variable or programmatic API:
NVIDIA_API_KEY=nvapi-... npm startimport { configureHyde } from './src/search/hybridRanker.js';
configureHyde({ apiKey: 'nvapi-...' });Defaults to nvidia/llama-3.1-nemotron-nano-8b-v1 on the NVIDIA NIM endpoint. Any OpenAI-compatible chat completion URL can be used via the apiUrl option.
mcp-server-3gpp/
├── src/
│ ├── index.js
│ ├── http.js
│ ├── db/
│ ├── search/
│ │ ├── hybridRanker.js (RRF fusion + structure-aware ranking)
│ │ ├── keywordSearch.js (FTS5 + BM25)
│ │ ├── semanticSearch.js (sqlite-vec)
│ │ ├── anytxtSearch.js (AnyTXT JSON-RPC retriever)
│ │ ├── hydeExpander.js (HyDE query expansion via NVIDIA LLM)
│ │ └── queryParser.js
│ ├── anytxt/
│ │ ├── client.js (JSON-RPC 2.0 client)
│ │ └── parser.js (document text extraction)
│ ├── tools/
│ └── ingest/
├── docs/
├── data/
│ └── corpus/
│ └── 3gpp.db
├── test/
├── validate.js
└── package.jsonThe documented operating model is the DB-backed v2 server.
There is still a legacy fallback path in src/index.js if no SQLite DB is found, but that is a bootstrap escape hatch, not the primary interface this repository documents.
get_section and get_spec_toc are the core deterministic retrieval tools. Search should feed them, not replace them.
Get detailed information about EMM cause (LTE) or 5GMM cause (5G) values
| Name | Required | Description | Default |
|---|---|---|---|
| causeNumber | Yes | The cause number (e.g., 3, 7, 15, 22) | |
| network | No | Network type: 'lte' for EMM cause (TS 24.301), '5g' for 5GMM cause (TS 24.501). Default: 'lte' |
| Name | Required | Description |
|---|---|---|
| cause | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states it 'gets' information, implying a read-only operation, but doesn't specify any behavioral traits like authentication needs, rate limits, error handling, or what 'detailed information' entails. For a tool with no annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding the tool's function. No waste or redundancy is present.
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 (simple lookup with two parameters), high schema coverage (100%), and the presence of an output schema (implied by context signals), the description is reasonably complete. It covers the core purpose and scope. However, without annotations, it lacks behavioral context, and the absence of usage guidelines reduces completeness for agent decision-making.
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 schema already documents both parameters thoroughly. The description doesn't add any meaning beyond what the schema provides—it mentions 'cause number' and 'network type' generically but doesn't elaborate on semantics, valid ranges beyond examples, or usage nuances. Baseline 3 is appropriate when the schema does the heavy lifting.
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 detailed information about EMM cause (LTE) or 5GMM cause (5G) values'. It specifies the verb ('Get'), resource ('detailed information'), and scope (LTE/5G cause values), though it doesn't explicitly differentiate from sibling tools like list_specs or search_3gpp_docs, which appear to be more general documentation 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or other contexts, leaving the agent to infer usage based on the tool name and parameters alone. There's no explicit when/when-not or alternative tool recommendations.
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 in the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| specs | Yes | |
| totalChunks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a listing operation, implying read-only behavior, but doesn't mention any constraints like pagination, rate limits, or what 'available' means (e.g., only active specs). This leaves significant gaps in understanding how the tool behaves.
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, clear sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and efficiently communicates the essential information, making it highly concise and well-structured.
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 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a listing tool with no annotations, it lacks details on behavioral aspects like result format or limitations, which could be helpful despite the output schema covering return values.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
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 action ('List') and resource ('available 3GPP specifications in the database'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_3gpp_docs', which likely offers filtering capabilities, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives like 'search_3gpp_docs'. It lacks context about whether this lists all specifications without filtering or if it's the default listing tool, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 3GPP specification documents (TS 24.008, TS 24.301, TS 24.501, TS 36.300) by keywords
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., 'EMM cause reject', 'attach procedure', 'tracking area update') | |
| spec | No | Optional: Filter by specification (e.g., 'TS 24.301', 'TS 24.501') | |
| maxResults | No | Maximum number of results to return (default: 5) |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search functionality but lacks critical details: it doesn't specify if this is a read-only operation, what the output format looks like (though an output schema exists), whether there are rate limits, or how results are ranked. The description is minimal and doesn't compensate for the absence of annotations, leaving behavioral traits largely undefined.
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 highly concise and front-loaded, consisting of a single sentence that directly states the tool's function. It includes relevant examples (e.g., document types) without unnecessary elaboration. Every word earns its place, making it efficient and easy to parse for an AI agent, with no wasted 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 moderate complexity (3 parameters, 1 required), 100% schema description coverage, and the presence of an output schema, the description is somewhat complete but has gaps. It adequately covers the basic purpose but lacks usage guidelines and behavioral details. The output schema likely handles return values, reducing the need for description there, but the absence of annotations and insufficient behavioral context lowers the score to a minimal viable level.
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, providing clear details for all three parameters (query, spec, maxResults). The description adds minimal value beyond the schema by listing example document types, but it doesn't elaborate on parameter usage, such as how the 'spec' filter interacts with the query or the implications of 'maxResults'. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't significantly enhance 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: searching 3GPP specification documents by keywords, with specific examples of document types (TS 24.008, TS 24.301, TS 24.501, TS 36.300). It distinguishes from sibling tools like 'get_emm_cause' (which likely retrieves specific EMM causes) and 'list_specs' (which likely lists available specifications) by focusing on keyword search functionality. However, it doesn't explicitly differentiate from potential overlapping search tools beyond the scope of 3GPP documents.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'get_emm_cause' (e.g., for broader searches vs. specific cause retrieval) or 'list_specs' (e.g., for content search vs. metadata listing). There's also no information about prerequisites, such as required authentication or access rights, leaving usage context implied but unspecified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: get_emm_cause retrieves specific technical details about cause values, list_specs provides a catalog of available specifications, and search_3gpp_docs performs keyword searches across documents. There is no overlap in functionality, making tool selection straightforward for an agent.
The tools follow a consistent verb_noun pattern (get_*, list_*, search_*), which is predictable and readable. The minor deviation is that search_3gpp_docs includes a domain prefix (3gpp) in the noun, but this does not break the overall consistency significantly.
With only 3 tools, the set feels thin for a server focused on 3GPP specifications, which could involve more operations like filtering, updating, or detailed document retrieval. However, it covers basic lookup and search functions, making it borderline but functional for limited use cases.
The tools provide core read/search capabilities (get, list, search) for 3GPP specifications, but there are notable gaps such as lack of create, update, or delete operations if the domain implies database management, and no tools for advanced filtering or cross-referencing. It supports basic queries but may leave agents unable to perform more complex tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted 3GPP MCP server for Rel-15–20 TS/TR search. Index stays current.
SIP/VoIP/telecom grounding for AI agents: vendor docs, RFCs, STIR/SHAKEN, traces, configs.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Search your knowledge bases from any AI assistant using hybrid RAG.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lee-SiHyeon/mcp-server-3gpp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
