MCP-сервер для спецификаций 3GPP и IETF RFC, работающий на основе предварительно созданного корпуса SQLite.
Текущая версия сервера v2 построена вокруг навигации по главам с помощью ИИ, а не жестко закодированной логики поиска протоколов. Предполагаемый рабочий процесс:
Обнаружение соответствующих спецификаций с помощью 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 строк оглавления (TOC)
45 162 перекрестных ссылок между спецификациями
Точка входа Stdio MCP в src/index.js
Опциональный транспорт Streamable HTTP в src/http.js
Related MCP server: IEEE 802.11 MCP Server
search_3gpp_docs предоставляет ключевой поиск с фразами в кавычках, фильтрами spec:, подсказками section: и отрицанием.
База данных и среда выполнения могут размещать эмбеддинги sqlite-vec через vec_sections.
Путь инструмента 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 |
Строк TOC | 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 на базе БД.
В src/index.js все еще существует устаревший резервный путь, если база данных SQLite не найдена, но это аварийный выход для загрузки, а не основной интерфейс, который документирует этот репозиторий.
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.
