사전 구축된 SQLite 코퍼스를 기반으로 하는 3GPP 및 IETF RFC 사양용 MCP 서버입니다.
현재 v2 서버는 하드코딩된 프로토콜 조회 로직이 아닌 AI 가이드 챕터 탐색을 중심으로 구축되었습니다. 권장되는 워크플로우는 다음과 같습니다:
get_spec_catalog 또는 search_3gpp_docs를 사용하여 관련 사양을 찾습니다.
get_spec_toc를 사용하여 챕터 구조를 살펴봅니다.
get_section을 사용하여 정확한 텍스트를 가져옵니다.
search_related_sections를 사용하여 로컬에서 확장합니다.
get_spec_references를 사용하여 문서 간을 이동합니다.
검색은 시작점일 뿐이며 제품의 전부가 아닙니다. 모델은 의도적으로 챕터를 탐색하고 선택해야 합니다.
8개의 MCP 도구가 포함된 DB 기반 v2 서버
data/corpus/3gpp.db에 사전 구축된 코퍼스
총 207개 사양: 112개 TS, 2개 TR, 93개 RFC
66,109개의 전체 섹션 및 63,376개의 목차(TOC) 행
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"
}
}서버는 다음 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는 패키지 메타데이터를 확인하고, DB 경로를 해결하며, 핵심 스키마와 개수를 검증하고, 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문서화된 운영 모델은 DB 기반 v2 서버입니다.
SQLite DB를 찾을 수 없는 경우를 대비한 레거시 대체 경로가 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.
