MCP-Server für 3GPP- und IETF-RFC-Spezifikationen, basierend auf einem vorgefertigten SQLite-Korpus.
Der aktuelle v2-Server basiert auf KI-gestützter Kapitelnavigation, nicht auf fest codierter Protokoll-Suchlogik. Der beabsichtigte Arbeitsablauf ist:
Relevante Spezifikationen mit get_spec_catalog oder search_3gpp_docs entdecken.
Die Kapitelstruktur mit get_spec_toc durchlaufen.
Den genauen Text mit get_section abrufen.
Lokal mit search_related_sections erweitern.
Mit get_spec_references zwischen Dokumenten springen.
Die Suche ist ein Ausgangspunkt, nicht das gesamte Produkt. Es wird erwartet, dass das Modell die Kapitel gezielt durchsucht und auswählt.
DB-basierter v2-Server mit 8 MCP-Tools
Vorgefertigter Korpus in data/corpus/3gpp.db
Insgesamt 207 Spezifikationen: 112 TS, 2 TR, 93 RFC
66.109 vollständige Abschnitte und 63.376 Inhaltsverzeichnis-Zeilen
45.162 Referenzverknüpfungen zwischen Spezifikationen
Stdio MCP-Einstiegspunkt in src/index.js
Optionaler Streamable HTTP-Transport in src/http.js
Related MCP server: IEEE 802.11 MCP Server
search_3gpp_docs bietet eine Stichwortsuche mit Phrasen in Anführungszeichen, spec:-Filtern, section:-Hinweisen und Negation.
Die Datenbank und Laufzeitumgebung können sqlite-vec-Einbettungen über vec_sections hosten.
Der Standard-MCP-Toolpfad ist weiterhin stichwortbasiert, sofern der Suchschicht keine Abfrage-Einbettungsfunktion bereitgestellt wird. Gehen Sie also nicht davon aus, dass semantisches Ranking aktiv ist, nur weil vec_sections existiert.
git lfs install
git clone https://github.com/Lee-SiHyeon/mcp-server-3gpp.git
cd mcp-server-3gpp
npm install
npm run validate
npm startDie mitgelieferte Datenbank wird mit Git LFS nachverfolgt. Ein erfolgreicher Start sieht so aus:
[3GPP MCP] Database ready: .../data/corpus/3gpp.db
[3GPP MCP] Features - FTS: true, Vector: true
[3GPP MCP] Registered 8 tools (v2 DB mode){
"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"
}
}Der Server prüft diese DB-Speicherorte in der folgenden Reihenfolge:
THREEGPP_DB_PATH
data/corpus/3gpp.db
data/3gpp.db
Tool | Zweck |
| Listet indizierte Spezifikationen mit Titel, Version, Serie, Beschreibung, Abschnittsanzahl und Seitenzahl auf. |
| Gibt die Kapitelhierarchie für eine Spezifikation zurück, optional begrenzt durch Tiefe oder Abschnittspräfix. |
| Ruft den genauen Abschnittstext über |
| Bewertet Kandidatenabschnitte für eine Abfrage und gibt Abschnitts-IDs für den weiteren Abruf zurück. |
| Erweitert von einem Ankerabschnitt aus über übergeordnete, untergeordnete, benachbarte und suchbasierte Nachbarn. |
| Durchläuft eingehende und ausgehende Zitate zwischen Spezifikationen. |
| Gibt operative Anweisungen für den ETSI-Download, RFC-Ingest oder die Extraktions-Pipeline zurück. |
| Kompatibilitäts-Alias mit einer kleineren Ausgabeform; bevorzugen Sie |
Verwenden Sie Prompts, die eine strukturorientierte Navigation fördern:
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.Metrik | Wert |
Gesamtzahl Spezifikationen | 207 |
TS-Spezifikationen | 112 |
TR-Spezifikationen | 2 |
RFC-Spezifikationen | 93 |
Inhaltsverzeichnis-Zeilen | 63.376 |
Abschnitts-Zeilen | 66.109 |
Referenzen zwischen Spezifikationen | 45.162 |
Aufgezeichnete Ingestions-Durchläufe | 535 |
LLM client
-> MCP transport (stdio or HTTP)
-> tool registry + validation
-> tool handlers
-> SQLite corpus (specs, toc, sections, sections_fts, spec_references, ingestion_runs)
-> optional vec_sections table and guide resourcesWeitere Details finden Sie in docs/architecture.md und docs/data-model.md.
npm run validate
npm testnpm run validate überprüft die Paketmetadaten, löst den DB-Pfad auf, verifiziert das Kernschema und die Anzahl der Einträge und bestätigt, dass der v2-Server die aktuelle 8-Tool-Oberfläche registriert.
mcp-server-3gpp/
├── src/
│ ├── index.js
│ ├── http.js
│ ├── db/
│ ├── search/
│ ├── tools/
│ └── ingest/
├── docs/
├── db/
├── data/
│ └── corpus/
│ └── 3gpp.db
├── test/
├── validate.js
└── package.jsonDas dokumentierte Betriebsmodell ist der DB-basierte v2-Server.
Es gibt weiterhin einen Legacy-Fallback-Pfad in src/index.js, falls keine SQLite-DB gefunden wird, aber dies ist ein Bootstrap-Notausgang, nicht die primäre Schnittstelle, die dieses Repository dokumentiert.
get_section und get_spec_toc sind die deterministischen Kern-Abrufwerkzeuge. Die Suche sollte diese füttern, nicht ersetzen.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0get_emm_causelist_specssearch_3gpp_docsScored across 3 tools
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.
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.
