用于 3GPP 和 IETF RFC 规范的 MCP 服务器，由预构建的 SQLite 语料库提供支持。
当前的 v2 服务器围绕 AI 引导的章节导航构建，而非硬编码的协议查找逻辑。预期的工作流程如下：
使用 get_spec_catalog 或 search_3gpp_docs 发现相关规范。
使用 get_spec_toc 浏览章节结构。
使用 get_section 检索确切文本。
使用 search_related_sections 在本地进行扩展。
使用 get_spec_references 在文档间跳转。
搜索是一个起点，而非完整的产品。模型应被引导去主动浏览并选择章节。
基于数据库的 v2 服务器，包含 8 个 MCP 工具
data/corpus/3gpp.db 中的预构建语料库
总计 207 个规范：112 个 TS，2 个 TR，93 个 RFC
66,109 个完整章节和 63,376 个目录行
45,162 个跨规范引用链接
src/index.js 中的 Stdio MCP 入口点
src/http.js 中的可选 Streamable HTTP 传输
Related MCP server: IEEE 802.11 MCP Server
search_3gpp_docs 提供关键字搜索，支持带引号的短语、spec: 过滤器、section: 提示和否定搜索。
数据库和运行时可通过 vec_sections 托管 sqlite-vec 嵌入。
默认的 MCP 工具路径仍然优先使用关键字搜索，除非向搜索层提供了查询嵌入函数，因此不要仅仅因为存在 vec_sections 就假设语义排序已启用。
git lfs install
git clone https://github.com/Lee-SiHyeon/mcp-server-3gpp.git
cd mcp-server-3gpp
npm install
npm run validate
npm start捆绑的数据库通过 Git LFS 进行跟踪。正常的启动过程如下：
[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"
}
}服务器按以下顺序检查数据库位置：
THREEGPP_DB_PATH
data/corpus/3gpp.db
data/3gpp.db
工具 | 用途 |
| 列出已索引的规范，包含标题、版本、系列、描述、章节数和页数。 |
| 返回规范的章节层级，可选择按深度或章节前缀进行限制。 |
| 通过 |
| 对查询的候选章节进行排序，并返回章节 ID 以供后续检索。 |
| 从锚点章节出发，通过父级、子级、同级和搜索衍生的邻近章节进行扩展。 |
| 遍历传入和传出的跨规范引用。 |
| 返回有关 ETSI 下载、RFC 摄取或提取管道的操作说明。 |
| 具有较小输出形状的兼容性别名；建议优先使用 |
使用鼓励结构优先导航的提示词：
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.指标 | 数值 |
规范总数 | 207 |
TS 规范 | 112 |
TR 规范 | 2 |
RFC 规范 | 93 |
目录行数 | 63,376 |
章节行数 | 66,109 |
跨规范引用 | 45,162 |
记录的摄取运行次数 | 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 resources更多详细信息请参阅 docs/architecture.md 和 docs/data-model.md。
npm run validate
npm testnpm run validate 会检查包元数据、解析数据库路径、验证核心模式和计数，并确认 v2 服务器是否注册了当前的 8 个工具界面。
mcp-server-3gpp/
├── src/
│ ├── index.js
│ ├── http.js
│ ├── db/
│ ├── search/
│ ├── tools/
│ └── ingest/
├── docs/
├── db/
├── data/
│ └── corpus/
│ └── 3gpp.db
├── test/
├── validate.js
└── package.json文档化的操作模型是基于数据库的 v2 服务器。
如果未找到 SQLite 数据库，src/index.js 中仍存在一个遗留的回退路径，但这只是一个引导应急方案，而非本仓库记录的主要接口。
get_section 和 get_spec_toc 是核心的确定性检索工具。搜索应作为它们的辅助，而非替代品。
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.
