Un servidor MCP (Model Context Protocol) que hace que las especificaciones 3GPP sean accesibles para los LLM.
Las especificaciones 3GPP son referencias esenciales para la ingeniería de telefonía móvil y telecomunicaciones, pero son difíciles de manejar eficazmente para los LLM:
Demasiados documentos - Existen miles de especificaciones en múltiples series, lo que dificulta encontrar la correcta.
Los documentos individuales son demasiado grandes - Muchas especificaciones tienen cientos de páginas, superando con creces las ventanas de contexto típicas.
Distribuidas como archivos de Word - Las especificaciones se publican en formato .docx / .doc y requieren conversión para el procesamiento de texto.
Gran cantidad de referencias cruzadas - Las especificaciones se referencian entre sí con frecuencia; leer un solo documento de forma aislada da una imagen incompleta.
Información contenida en tablas y figuras - Las tablas complejas y los diagramas de flujo contienen detalles críticos. Esta herramienta convierte las tablas a Markdown y extrae las imágenes incrustadas para su visualización por parte del LLM.
Complejidad de versiones - Una misma especificación existe en múltiples releases de 3GPP, e identificar la versión correcta es importante.
Esta herramienta aborda estos desafíos analizando los archivos .docx, estructurando el contenido por sección y almacenándolo todo en una base de datos SQLite con búsqueda de texto completo (FTS5). Un servidor MCP expone entonces herramientas para buscar, navegar por secciones y seguir referencias cruzadas, permitiendo que un LLM navegue por las especificaciones como lo haría un ingeniero.
El RAG basado en embeddings es una forma común de mejorar la precisión en preguntas y respuestas sobre documentos, y existen sistemas RAG especializados para documentos 3GPP (Telco-RAG, TelcoAI). Esta herramienta adopta un enfoque más simple: en lugar de construir un pipeline de recuperación delante del modelo, le proporciona al modelo herramientas de búsqueda y navegación y le permite explorar las especificaciones como lo haría un ingeniero: búsqueda de texto completo, luego seguimiento de la jerarquía de secciones y referencias cruzadas. Dado que la recuperación es una simple búsqueda FTS5 sobre secciones estructuradas, no hay ningún modelo de embeddings ni base de datos vectorial que ejecutar, y todo reside en un único archivo SQLite.
Medido en TeleQnA, esto mejora la precisión en preguntas sobre estándares 3GPP entre 6.5 y 12.0 puntos porcentuales en tres familias de modelos. La mayor parte se debe a tener el texto en sí: una sola consulta BM25 sobre la misma base de datos representa entre +7.8 y +9.6 puntos de esa mejora. La propia búsqueda de la herramienta es lo que marca la diferencia en preguntas cuya respuesta se encuentra a más de un salto del primer pasaje recuperado; en tareas generadas a partir de las propias especificaciones (códigos de protocolo, estructura ASN.1, esquemas SBI de 5G) responde y cita correctamente entre el 88 y el 100%, superando esa misma línea base BM25 entre +26 y +88 puntos en cada tipo de tarea y cada modelo. Consulte BENCHMARK.md.
Related MCP server: mcp-docs
# Homebrew
brew install higebu/tap/3gpp-mcp
# ...or with Go 1.26+
go install github.com/higebu/3gpp-mcp/cmd/3gpp-mcp@latestTambién hay binarios precompilados disponibles en la página de releases. LibreOffice es opcional (necesario para la conversión de .doc a .docx y de imágenes EMF/WMF a PNG).
Descargar e importar las especificaciones en la base de datos. Los archivos temporales se eliminan después de procesar cada especificación, minimizando el uso de disco.
# Download and import the latest version of every spec (all releases)
3gpp-mcp build --latest --db data/3gpp.db --convert-doc --convert-image
# ...or restrict to a single release
3gpp-mcp build --release 19 --db data/3gpp.db --convert-doc --convert-imageEsto raspará el archivo FTP de 3GPP, descargará archivos ZIP, extraerá y analizará archivos .docx, e insertará el contenido estructurado en la base de datos SQLite.
claude mcp add --scope user 3gpp -- 3gpp-mcp serve --db /path/to/data/3gpp.dbcode --add-mcp '{"name":"3gpp","command":"3gpp-mcp","args":["serve","--db","/path/to/data/3gpp.db"]}'Añadir a ~/.config/github-copilot/cli-mcp.json (crear si no existe):
{
"mcpServers": {
"3gpp": {
"command": "3gpp-mcp",
"args": ["serve", "--db", "/path/to/data/3gpp.db"]
}
}
}codex mcp add --name 3gpp --command 3gpp-mcp --args serve --db /path/to/data/3gpp.dbAñadir a su archivo de configuración (~/Library/Application Support/Claude/claude_desktop_config.json en macOS, %APPDATA%\Claude\claude_desktop_config.json en Windows):
{
"mcpServers": {
"3gpp": {
"command": "3gpp-mcp",
"args": ["serve", "--db", "/path/to/data/3gpp.db"]
}
}
}Navegue por las especificaciones en su navegador añadiendo --web al transporte HTTP:
3gpp-mcp serve --db data/3gpp.db --transport http --addr :8080 --web
# MCP endpoint: http://localhost:8080/mcp/
# Web viewer: http://localhost:8080/Características: lista de especificaciones con filtrado, visor de secciones con barra lateral de TOC, búsqueda de texto completo con paginación, navegación por versiones anteriores (las versiones se listan por especificación y se descargan bajo demanda, como las herramientas MCP), comparación de versiones (resumen estructural y diferencias por sección), imágenes incrustadas, enlaces de referencias cruzadas, definiciones OpenAPI con resaltado de sintaxis, renderizado KaTeX de las fórmulas LaTeX que emite el convertidor, modo oscuro, diseño adaptativo. Los bloques de código tienen resaltado de sintaxis por notación: ASN.1, Diameter, SIP/RTSP, SDP y XML (consulte Bloques de código).
Cuando el navegador proporciona la API W3C WebMCP (document.modelContext, un origin trial de Chrome a partir de 2026), el visor registra todas sus herramientas MCP con el navegador al cargar la página, de modo que un agente en el navegador pueda consultar la base de datos de especificaciones directamente. El registro es un paso a través del mismo origen hacia el endpoint /mcp/; no hay nada que configurar en el lado del servidor, y los navegadores sin la API no se ven afectados. Durante el origin trial, actívelo localmente mediante las banderas de Chrome (chrome://flags), o para un despliegue compartido sirva un encabezado Origin-Trial desde un proxy frontal.
El transporte HTTP es sin estado: soporta la versión 2026-07-28 del protocolo MCP (sin handshake de inicialización, sin Mcp-Session-Id) mientras que los clientes más antiguos (2024-11-05 hasta 2025-11-25) siguen funcionando mediante sesiones por solicitud.
Inicie el servidor con transporte HTTP:
3gpp-mcp serve --db data/3gpp.db --transport http --addr :8080Opcionalmente, active la autenticación mediante token Bearer:
export THREEGPP_MCP_BEARER_TOKEN=$(openssl rand -hex 32)
3gpp-mcp serve --db data/3gpp.db --transport http --addr :8080Luego configure su cliente para conectarse vía HTTP:
{
"mcpServers": {
"3gpp": {
"url": "http://your-server:8080",
"headers": {
"Authorization": "Bearer YOUR_SECRET_TOKEN"
}
}
}
}Cuando se usa --web, el endpoint MCP se mueve a /mcp/.
Consulte examples/systemd/ para el despliegue en producción con systemd.
El Dockerfile es multi-etapa y construye la base de datos para una release directamente, produciendo una imagen autocontenida con la base de datos SQLite (secciones, definiciones OpenAPI e imágenes incrustadas) incluida. No se necesita ninguna base de datos preconstruida en el contexto de construcción.
# Build an image with the latest version of every spec baked in (default)
docker build -t 3gpp-mcp:latest .
# ...or restrict the database to a single release
docker build --build-arg RELEASE=19 -t 3gpp-mcp:rel19 .
# ...or cap the newest release, keeping specs that have no version in it
docker build --build-arg MAX_RELEASE=19 -t 3gpp-mcp:max-rel19 .
# stdio transport (Claude Code / IDE integration)
docker run --rm -i 3gpp-mcp:latest
# HTTP transport
docker run --rm -p 8080:8080 3gpp-mcp:latest serve --db /3gpp.db --transport http --addr :8080RELEASE por defecto es latest, que incluye la última versión de cada especificación en todas las releases. Establezca --build-arg RELEASE=<n> (ej. 19) para restringir la base de datos a una sola release, o --build-arg MAX_RELEASE=<n> para limitar la release más nueva sin eliminar especificaciones que no tengan versión en ella. Los dos no se pueden combinar.
Para ejecutar en Cloud Run, consulte cloudbuild.yaml (build + push + deploy) y service.yaml (especificación del servicio Cloud Run).
Cada herramienta a continuación también tiene un gemelo CLI (list_specs → 3gpp-mcp list-specs, y así sucesivamente) para uso en shell y scripting — consulte los comandos de consulta en la Referencia de comandos.
Herramienta | Descripción | Parámetros clave |
| Listar las especificaciones disponibles (paginado) |
|
| Listar las versiones de una especificación y desde dónde se puede leer cada una |
|
| Obtener la tabla de contenidos de una especificación |
|
| Obtener el contenido de una sección (paginado) |
|
| Comparar dos versiones de una especificación: resumen estructural o diff de texto de sección |
|
Cada resultado de get_toc, get_section y search nombra la especificación y versión de la que proviene, en cada página de una respuesta paginada.
La base de datos contiene una versión por especificación. Para leer otra versión, pase version a get_section o get_toc. version acepta la forma con puntos (15.8.0), el token de archivo (f80), un selector de release (Rel-15 o 15, que elige la versión más nueva en esa release), o latest. Los selectores de release y latest se resuelven contra el archivo de 3GPP, por lo que requieren descarga bajo demanda (no funcionan con --no-fetch). old_version y new_version de compare_versions aceptan las mismas formas; new_version por defecto es la versión en la base de datos.
Una versión que no está en la base de datos se descarga del archivo de 3GPP y se convierte en el primer uso. Esto puede tomar hasta unos minutos para una especificación grande; si aún se está ejecutando cuando expira el presupuesto de la llamada, la herramienta lo indica y la misma llamada repetida más tarde devuelve el contenido. Los resultados se guardan en una caché de tamaño limitado (consulte serve) que está separada de la base de datos principal, por lo que:
search cubre solo la versión en la base de datos — no se admite la búsqueda de texto completo entre releases
get_references solo tiene datos para la versión en la base de datos, y una sección leída de una versión archivada lo indica en su encabezado
get_image y list_images también aceptan version: las imágenes de una versión archivada se descargan en su primer uso (una descarga de archivo adicional por versión, con el mismo comportamiento de reintento), y las figuras EMF/WMF se convierten a PNG cuando LibreOffice está instalado en el servidor
los números de sección se mueven entre releases; verifique get_toc para la versión anterior antes de leer una sección de la misma
Herramienta | Descripción | Parámetros clave |
| Búsqueda de texto completo en todas las especificaciones |
|
La herramienta search admite la sintaxis de consulta FTS5 de SQLite:
Búsqueda de frase: "service based interface"
Operadores booleanos: AMF AND UE, AMF OR SMF, NOT deprecated
Exclusión después de un término positivo: handover -conditional
Coincidencia de prefijo: handov*
Filtro de columna: title:authentication, content:handover
Proximidad: NEAR(AMF UE, 5)
Los términos que contienen guiones o puntos (IMS-AKA, 38.101) se citan automáticamente, por lo que no necesitan escape manual.
Herramienta | Descripción | Parámetros clave |
| Obtener referencias cruzadas entre especificaciones y RFCs |
|
Herramienta | Descripción | Parámetros clave |
| Listar definiciones OpenAPI disponibles |
|
| Obtener definición OpenAPI (paginada) |
|
| Búsqueda de texto completo en definiciones OpenAPI |
|
search_openapi utiliza su propio índice FTS5, separado del que usa search:
search cubre el texto de las cláusulas de especificación y nunca devuelve contenido OpenAPI,
search_openapi cubre solo contenido OpenAPI. Un acierto es una definición en lugar de
un documento — un esquema de components.schemas, o un método HTTP de una
ruta (nombrado como PUT /nf-instances/{nfInstanceID}) — así que puedes encontrar un
tipo de dato o un endpoint sin saber qué documento de API lo define, y luego leerlo
completamente con get_openapi. Una consulta que es un único término simple ordena primero una
definición con exactamente ese nombre, por lo que NFProfile devuelve el esquema NFProfile
antes que los esquemas que solo lo referencian.
El texto indexado de un esquema lleva un nivel de expansión de $ref — a través de items
y additionalProperties además de directamente, que es como las definiciones de 5G SBI
expresan la mayoría de sus relaciones — por lo que los campos de un tipo referenciado son
buscables desde el esquema que lo usa; un tipo a dos saltos de distancia no está
en ese texto. A diferencia de search, este índice no aplica stemming
— los identificadores se comparan tal como están escritos — y -, . y _ dividen tokens, por lo que
Nnrf_NFManagement también se encuentra mediante NFManagement y /nf-instances mediante
instances. camelCase no se divide.
El índice se construye al final de build y update. import e import-dir
lo dejan intacto: los archivos YAML se incluyen en el archivo zip, por lo que importar un .docx
no puede cambiar lo que hay que indexar. Una base de datos construida antes de que existiera esta herramienta
no tiene índice; añádelo en su lugar con
build-openapi-index.
Herramienta | Descripción | Parámetros clave |
| Obtener una asignación ASN.1 por nombre — en una especificación o en todas ellas — o listar los nombres de asignación de una especificación |
|
Los protocolos especificados en ASN.1 (RRC TS 38.331/36.331, NGAP TS 38.413, S1AP
TS 36.413, XnAP, F1AP, ...) escriben su ASN.1 entre los marcadores -- ASN1START /
-- ASN1STOP, que el convertidor almacena como bloques de código ```asn1 (ver
Bloques de código). get_asn1 extrae cada asignación de nivel superior —
tipos, constantes y objetos de información — de esos bloques.
Con name devuelve el texto completo de esa asignación junto con la sección
que la define, para que la respuesta pueda ser citada. Esto es importante para los protocolos
que definen todas sus IE en una cláusula: la cláusula de definiciones de IE de NGAP tiene
cientos de kilobytes, mucho más de lo que cabe en una página de get_section, mientras que la única definición
que responde "¿qué rango permite el ASN.1 aquí?" son unas pocas líneas. La coincidencia
ignora mayúsculas/minúsculas y separadores, por lo que el AMF UE NGAP ID de la tabla de IE encuentra
el AMF-UE-NGAP-ID del ASN.1; un nombre que no coincide con nada sugiere nombres similares.
Un nombre definido más de una vez devuelve cada definición, cada una bajo su propia línea de origen.
Cuando no sabes qué especificación define un nombre, omite spec_id: el
nombre se resuelve en todas las especificaciones de la base de datos, a partir de un índice
construido en el momento de la construcción de la base de datos (build, update, import e
import-dir lo actualizan). Una búsqueda que nombra la especificación incorrecta recibe
información sobre dónde está realmente definido el nombre. Una base de datos construida antes de que existiera esta herramienta
no tiene índice — añádelo en su lugar con
build-asn1-index. La resolución entre especificaciones cubre solo las
versiones de la base de datos — pasa spec_id (y opcionalmente version) para leer
una versión archivada, con el mismo comportamiento de descarga bajo demanda que
get_section.
Con un spec_id y sin name lista todos los nombres de asignación, agrupados por
sección definitoria.
Herramienta | Descripción | Parámetros clave |
| Listar imágenes incrustadas en una especificación |
|
| Obtener una imagen incrustada como datos base64 visibles por LLMs |
|
Las imágenes PNG/JPEG/GIF/WebP son directamente visibles por los LLMs. Las imágenes EMF/WMF (la mayoría de las figuras 3GPP usan este formato) se almacenan como datos sin procesar por defecto; usa --convert-image para convertirlas a PNG mediante LibreOffice en tiempo de construcción.
Las figuras se referencian desde el texto de la sección en una notación única, sea cual sea el formato
de la imagen:  en el texto del cuerpo y
<img src="image://NAME?w=&h=" ...> dentro de las celdas de tabla. Pasa ese NAME a
get_image; tanto el nombre de archivo original (image3.emf) como el convertido
(image3.png) se resuelven.
El texto de la sección lleva bloques de código etiquetados, para que tanto los LLMs como el visor web puedan distinguir las notaciones:
Bloque | Contenido |
| Módulos ASN.1 entre los marcadores |
| Definiciones de comandos Diameter y AVP agrupados (RFC 6733 CCF) |
| Esquemas XML, ejemplos de cuerpo XML y DTDs |
| Ejemplos de mensajes SIP/RTSP |
| Descripciones de sesión SDP independientes |
| Ecuaciones independientes convertidas desde Word OMML |
| Cualquier otra cosa que el documento fuente estilice como código |
Las fórmulas de Word (OMML) se convierten a LaTeX en tres notaciones, para que una fórmula sea legible tanto si está sola como si está dentro de una frase:
Notación | Dónde |
Bloque | Un párrafo cuyo único contenido es una ecuación. Su número de ecuación se conserva como |
| Ecuaciones en línea que no pueden ser un bloque delimitado — dentro de una celda de tabla o un elemento de lista. |
| Una fórmula dentro de una frase. |
La prosa de 3GPP codifica la estructura en la sangría — listas anidadas de requisitos y
condiciones, definiciones multinivel. El espacio en blanco inicial de un párrafo del cuerpo
se conserva como espacios de no separación (U+00A0), convirtiéndose una tabulación del documento fuente en
cuatro: una tabulación literal o 4+ espacios iniciales convertirían la línea
en un bloque de código indentado en Markdown (dentro del cual el HTML como
<sub> nunca se interpreta), mientras que los espacios de no separación mantienen el anidamiento visual
en cualquier renderizador y no interfieren con la búsqueda de texto completo.
Adjuntar el servidor no hace por sí mismo que un modelo lo consulte: si se le da la opción, algunos modelos responden preguntas sobre 3GPP de memoria. En el benchmark, Claude Sonnet 5 omitió la recuperación en el 40% de las preguntas de TeleQnA y GPT 5.6 Luna en el 60%, y en esas preguntas las herramientas no sirvieron de nada. Una frase en el prompt del sistema del cliente elimina esa discreción. El texto medido:
No respondas de memoria. Busca primero en las especificaciones y basa tu respuesta en el texto que recuperes, incluso cuando estés seguro de que ya sabes la respuesta.
Esa frase redujo la tasa de omisión de Luna a cero y su ganancia de +5.9 a +12.0 puntos, no movió nada en un modelo que ya buscaba en cada pregunta, y no vale nada sin las herramientas adjuntas — fuerza la recuperación en lugar de colar una respuesta. Reglas internas más estrictas en el mismo espíritu — basa cada respuesta sobre 3GPP en el texto de las cláusulas recuperado a través de estas herramientas, y cita la cláusula — son razonables, pero solo la frase anterior es la que midió el benchmark.
Para comparaciones puntuales entre releases, compare_versions y el parámetro version no necesitan configuración adicional. Construir una base de datos separada por release sigue siendo rentable cuando trabajas continuamente contra un release: la búsqueda de texto completo search, get_references y las definiciones OpenAPI solo cubren la versión integrada en la base de datos, por lo que una base de datos específica de un release te da los tres para ese release, sin descargas bajo demanda.
# Build databases for different releases
3gpp-mcp build --release 18 --db data/3gpp-rel18.db --convert-doc --convert-image
3gpp-mcp build --release 19 --db data/3gpp-rel19.db --convert-doc --convert-image--release mantiene solo las especificaciones que tienen una versión en ese release exacto, por lo que una
especificación congelada en un release anterior (TS 34.108, por ejemplo) falta en la base de datos
por completo. Para fijar un release sin perder esas especificaciones, limita la selección
en su lugar — cada especificación se toma en su versión más nueva en o por debajo del límite:
# Everything as of Release 19: specs with no Rel-19 version fall back to their
# newest older version rather than dropping out.
3gpp-mcp build --max-release 19 --db data/3gpp-rel19.db --convert-doc --convert-image
# Keep the cap when refreshing the database later.
3gpp-mcp update --max-release 19 --db data/3gpp-rel19.db --convert-docRegístralos como servidores MCP separados:
claude mcp add --scope user 3gpp-rel18 -- 3gpp-mcp serve --db /path/to/data/3gpp-rel18.db
claude mcp add --scope user 3gpp-rel19 -- 3gpp-mcp serve --db /path/to/data/3gpp-rel19.dbUsa el comando update para buscar versiones más recientes de las especificaciones ya en tu base de datos:
3gpp-mcp update --db data/3gpp.db --convert-doc --convert-imageserveIniciar el servidor MCP.
Bandera | Descripción | Valor por defecto |
| Ruta a la base de datos SQLite |
|
| Tipo de transporte: |
|
| Dirección de escucha HTTP (variable de entorno: |
|
| Token Bearer para autenticación HTTP (variable de entorno: | |
| Habilitar el visor web junto al servidor MCP (solo transporte HTTP) |
|
| Deshabilitar la obtención bajo demanda de versiones de especificaciones que no están en la base de datos |
|
| Ruta a la caché de versiones bajo demanda |
|
| Límite de tamaño de la caché de versiones en MB. |
|
| Cuánto tiempo espera una llamada de herramienta por una obtención bajo demanda antes de pedir al llamante que reintente (variable de entorno: |
|
La caché de versiones es un archivo SQLite separado, por lo que la base de datos principal permanece de solo lectura y nunca se contamina con versiones adicionales. Cuando no se puede crear la caché — un sistema de archivos de solo lectura o efímero, como la imagen de contenedor basada en scratch — el servidor registra una advertencia y se ejecuta con la obtención bajo demanda deshabilitada; todo lo demás sigue funcionando. Las versiones en caché se eliminan según la política de menos recientemente usada una vez que se supera el límite de tamaño.
El transporte HTTP también expone GET /health, que devuelve 200 OK sin autenticación. Use esta ruta para comprobaciones de estado de la plataforma (Cloud Run, Sakura AppRun, sondas de vida/readiness de Kubernetes, etc.).
buildDescargar e importar especificaciones en la base de datos (recomendado para la configuración inicial). Alias: pipeline.
Bandera | Descripción | Valor por defecto |
| Ruta de salida de la base de datos SQLite |
|
| Procesar especificaciones para un lanzamiento específico (ej. | |
| Limitar la selección a un lanzamiento (ej. | |
| Seleccionar cada especificación en su versión más reciente (usar cuando no se da otro selector) |
|
| Procesar una especificación específica (ej. | |
| Filtrar por serie, separadas por comas (ej. | |
| Número de trabajadores paralelos | NumCPU |
| Convertir archivos |
|
| Convertir imágenes EMF/WMF a PNG usando LibreOffice |
|
| Leer la lista de especificaciones desde un archivo en lugar de raspar el archivo (se sigue requiriendo un selector) | |
| Deshabilitar la caché de la lista de especificaciones |
|
| Concurrencia para raspar listados de especificaciones ( |
|
| Tiempo de espera HTTP |
|
Se debe proporcionar uno de --release, --max-release, --latest, --series o --spec, incluido --spec-list: el archivo proporciona las entradas candidatas y el selector las filtra.
--release y --max-release difieren en lo que sucede con una especificación que no tiene versión en el lanzamiento nombrado: --release 19 la descarta, --max-release 19 la mantiene en su versión más nueva por debajo del límite. No se pueden combinar.
download — Descargar especificaciones sin conversión (--output-dir, por defecto specs). Requiere uno de --release, --max-release, --latest, --series o --spec, como build.
import — Importar un único archivo .docx en la base de datos. Alias: convert. Uso: 3gpp-mcp import --db data/3gpp.db ruta/a/spec.docx
import-dir — Importar todos los archivos .docx en un directorio a la base de datos. Alias: convert-dir. Uso: 3gpp-mcp import-dir --db data/3gpp.db ./specs
update — Actualizar las especificaciones en la base de datos a las versiones más recientes, o a un límite con --max-release.
build-openapi-index — Reconstruir el índice de búsqueda OpenAPI de una base de datos existente. build y update hacen esto por sí mismos, por lo que es para agregar el índice a una base de datos construida antes de que existiera search_openapi: serve abre la base de datos en modo solo lectura y no puede crearlo sobre la marcha.
build-asn1-index — Reconstruir el índice de nombres ASN.1 de una base de datos existente. build, update, import y import-dir hacen esto por sí mismos, por lo que es para agregar el índice a una base de datos construida antes de que existiera get_asn1.
completion — Imprimir un script de completado de shell: 3gpp-mcp completion bash (o zsh, fish)
El límite no se almacena en la base de datos, por lo que una base de datos construida con --max-release 19 necesita la misma bandera en update; de lo contrario, la actualización eleva cada especificación a la versión más reciente en el archivo. Con un límite, la actualización mueve una especificación en cualquier dirección, por lo que también reduce una base de datos ya construida sin límite al límite; una especificación cuya versión está por encima del límite se elimina, ya que ninguna versión de ella pertenece a una base de datos limitada. Una especificación que falta en el listado del archivo se deja intacta, ya que un listado fallido se ve igual que una especificación retirada.
Los comandos de consulta (list-specs, list-versions, get-toc, get-section,
get-asn1, compare-versions, search, list-openapi, get-openapi,
search-openapi, get-references, list-images, get-image) reflejan las herramientas de lectura MCP 1:1, por lo que la base de datos se puede inspeccionar y scriptear desde un shell sin un cliente MCP:
3gpp-mcp search --db data/3gpp.db --limit 3 "AMF AND authentication" | jq '.results[].section_number'
3gpp-mcp get-section --db data/3gpp.db "TS 23.501" 5.15.2 | lessConvenciones compartidas por todos:
Las banderas deben ir antes de los argumentos posicionales.
Los resultados JSON se imprimen en stdout con sangría y sin paginación — canalice a jq, head o less. Las advertencias y notas de progreso van a stderr, por lo que stdout se mantiene analizable.
Los comandos que aceptan --version (y compare-versions) toman las mismas formas de versión que las herramientas MCP (15.8.0, f80, Rel-15, latest) y esperan a que finalice una descarga bajo demanda en lugar de pedirle que reintente; interrumpa con Ctrl-C. Comparten las banderas de obtención de serve: --no-fetch, --version-cache, --version-cache-mb, --fetch-budget. Las consultas que no nombran ninguna versión nunca crean la caché de versiones (list-versions lee una caché existente para informar disponibilidad cached, pero no creará una).
Cada comando toma --db (por defecto 3gpp.db).
Variable | Descripción |
| Transporte para |
| Dirección de escucha HTTP para |
| Token Bearer para autenticación de transporte HTTP |
| Convención PaaS (Cloud Run / Heroku); |
| Límite de tamaño de la caché de versiones bajo demanda en MB (por defecto |
| Cuánto tiempo espera una llamada de herramienta por una obtención bajo demanda (por defecto |
| Tamaño máximo de descarga ZIP (por defecto |
| TTL de la caché de la lista de especificaciones en horas (por defecto |
| Retroceso inicial entre intentos de obtención del listado del archivo en ms (por defecto |
| Raíz del directorio de caché, según la especificación XDG Base Directory |
Compare two versions of a 3GPP specification. Without section_number, returns a structural summary: sections added, removed, renumbered, retitled, and whose content changed. With section_number, returns a line-level unified diff of that section's text. Use list_versions first to see which versions exist; a version not yet cached is downloaded and converted on first use — when the tool says a download is in progress, call it again with the same arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Start line number (0-based, default: 0) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| max_chars | No | Maximum number of characters to return (can be combined with max_lines) | |
| max_lines | No | Maximum number of lines to return (default: 200) | |
| new_version | No | Newer version to compare to. Defaults to the version in the database. | |
| old_version | Yes | required,Older version to compare from (e.g. 17.9.0). Also accepts an archive token (h90) or a release selector (Rel-17). Use list_versions to see what exists. | |
| context_lines | No | Unchanged lines shown around each change in a section diff (default: 3) | |
| section_number | No | Compare only this section's text as a unified diff (e.g. 5.15.2). Omit for a structural summary of the whole specification. | |
| include_subsections | No | With section_number: include subsections in the diff (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It transparently discloses that uncached versions trigger a download that may require a second call. It also explains the two output modes. While it doesn't cover all potential edge cases (e.g., error handling), the key behavioral trait is well documented.
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 concise: four sentences covering two distinct modes, prerequisites, and first-use behavior. No redundant words. Information is front-loaded with the core purpose.
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 9 parameters and no output schema, the description is remarkably complete. It explains the two output modes, how to pick versions, and the caching behavior. The only minor gap is that it doesn't describe the format of the structural summary, but that's a niche detail. Overall, it provides sufficient context for correct tool invocation.
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 baseline is 3. However, the description adds significant context beyond the schema: it explains how 'section_number' changes the output type (summary vs. diff), and gives concrete examples like '5.15.2'. The 'old_version' description also clarifies it accepts archive tokens and release selectors, which is not in the schema. This adds substantial semantic value.
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 starts with 'Compare two versions of a 3GPP specification', clearly defining the verb and resource. It then distinguishes two modes: without section_number (structural summary) and with section_number (line-level diff). This differentiates it from sibling tools like 'get_section' or 'list_versions'.
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 explicitly tells when to use each mode and directs to use 'list_versions first to see which versions exist'. It also explains behavior on first use (download/conversion) and instructs to retry if a download is in progress. This is clear guidance on usage vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ASN.1 definitions from the 3GPP specifications. The protocol specifications (RRC TS 38.331/36.331, NGAP TS 38.413, S1AP TS 36.413, XnAP, F1AP, LPP TS 37.355, ...) write their ASN.1 between -- ASN1START / -- ASN1STOP markers, and this tool extracts every top-level assignment from those blocks. With name, it returns the full text of that assignment — type, constant or information object — together with the specification and section that define it, so the answer can be cited. Use it when you know a type, IE or constant name and need its definition or constraints: the defining clause can be hundreds of kilobytes, which get_section can only page through. If you do not know which specification defines the name, omit spec_id — the name is resolved across every specification in the database. Matching ignores case and separators, so an IE table title like 'AMF UE NGAP ID' finds AMF-UE-NGAP-ID. With a spec_id and no name, it lists every assignment name grouped by the section that defines it. Pass version (with spec_id) to read a past version, which is downloaded and converted on first use; call list_versions first to see which versions exist.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ASN.1 assignment name (e.g. AMF-UE-NGAP-ID). Matching ignores case and separators, so an IE title like 'AMF UE NGAP ID' also resolves. Required when spec_id is omitted; with a spec_id, omit it to list every assignment name in the specification. | |
| offset | No | Start line number (0-based, default: 0) | |
| spec_id | No | Specification ID (e.g. TS 38.413). Omit it to look the name up across every specification in the database — use that when you do not know which specification defines the type. | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database, and requires spec_id. Use list_versions to see what exists. | |
| max_chars | No | Maximum number of characters to return (can be combined with max_lines) | |
| max_lines | No | Maximum number of lines to return (default: 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the scope of extraction (only top-level assignments from blocks between ASN1START/ASN1STOP markers), behavior with and without the name parameter, case-insensitive and separator-ignoring matching, and handling of past versions (downloaded and converted on first use). Since no annotations are provided, the description carries full burden, which it largely fulfills, though it could be more explicit about potential limitations (e.g., if the tool is destructive or read-only).
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 moderately concise for the amount of information conveyed, but it is somewhat lengthy (multiple sentences). It is front-loaded with the core purpose, then progressively adds details on usage modes, matching behavior, and version handling. Every sentence adds value, but some redundancy could be trimmed (e.g., explaining matching behavior both in the main description and in the parameter description).
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 (6 parameters, multiple usage modes, no output schema), the description provides comprehensive guidance on how the tool behaves in different scenarios (with/without name, with/without spec_id, with version). It also addresses how to cite results and how to discover versions. The only gap is the lack of information about the return format or output structure, but since there is no output schema, the description could be more explicit about what the tool returns (e.g., structured text, markdown, etc.).
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 each parameter is already documented in the schema. The description adds extra context beyond the schema, such as the effect of omitting spec_id to search across all specs, the matching behavior (case-insensitive, separator-ignoring), and the fact that name is required when spec_id is omitted. It also explains the version parameter behavior and recommends list_versions. However, since schema coverage is complete, the description exceeds the baseline of 3 but does not substantially add new meaning for every parameter.
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 extracts ASN.1 definitions from 3GPP specifications, specifying verb ('Get', 'extracts') and resource ('ASN.1 definitions from the 3GPP specifications'). It distinguishes it from siblings like get_section by explaining that the defining clause can be hundreds of kilobytes, which get_section can only page through.
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 explicitly states when to use this tool (e.g., 'Use it when you know a type, IE or constant name and need its definition or constraints') and when to use alternatives (e.g., 'the defining clause can be hundreds of kilobytes, which get_section can only page through'). It also provides guidance on omitting spec_id when the specification is unknown, and directs users to call list_versions first to see available versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an embedded image from a 3GPP specification. Returns the image as base64-encoded data that can be directly viewed by the LLM. Use list_images to discover available images for a spec. Pass version to read a past version's image; the images of an archived version are downloaded on first use, which takes up to a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | required,Image filename (e.g. image1.png) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it states the output is base64-encoded, mentions a latency caveat for archived versions ('up to a few minutes'), and explains the default version behavior. This fully discloses behavioral traits.
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 three sentences, front-loaded with the main action and output, and each sentence adds unique value. Could be slightly more concise by combining the first two sentences, but no superfluous content.
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 no output schema and 3 parameters, the description covers tool purpose, input semantics, latency behavior, and next steps via sibling links. It does not mention what happens if parameters are invalid or if an image doesn't exist, but the overall completeness is high for the context.
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 coverage is 100% and already explains each parameter well. The description adds value by clarifying `version` accepts both version strings and archive tokens, and defaults to the database version, which goes beyond the schema description.
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 uses specific verbs ('Get an embedded image') and resource ('3GPP specification'), and clearly distinguishes this tool from siblings like `list_images` by stating its function and output format.
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 explicitly points to `list_images` for discovering available images and `list_versions` for version discovery, providing clear guidance on when to use alternative tools. However, it does not mention when not to use this tool (e.g., for non-image content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenAPI definition content for 5G service-based interface APIs (TS 29.xxx series). Use this tool to look up HTTP request/response details, API paths, parameters, request bodies, response schemas, and data type definitions. Use the path parameter to filter by API endpoint (e.g. /nf-instances) or the schema parameter to filter by data type (e.g. NFProfile). Use list_openapi first to discover available API names.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Filter by API path (e.g. /nf-instances) | |
| offset | No | Start line number for pagination (0-based, default: 0) | |
| schema | No | Filter by schema name (e.g. NFProfile) | |
| spec_id | Yes | required,Specification ID (e.g. TS 29.510) | |
| api_name | Yes | required,API name (e.g. Nnrf_NFManagement) | |
| max_lines | No | Maximum lines to return (default: 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as a 'get' and 'look up' operation, implying it is read-only and non-destructive. However, it does not explicitly state that it is safe, nor does it mention pagination behavior (offset, max_lines) or what happens in edge cases like no results. The description is adequate but lacks explicit behavioral details beyond the verb choice.
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 three sentences long, front-loading the purpose in the first sentence and then elaborating on capabilities and usage. Every sentence contributes meaningful information without redundancy or fluff. It is compact and immediately informative.
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?
With 6 parameters, no output schema, and no annotations, the description should provide a thorough understanding of the tool. It covers the main purpose, prerequisite workflow, and parameter usage, but it does not describe the output format (e.g., JSON/YAML), the meaning of offset and max_lines for pagination, or error handling. This leaves gaps in what a user can expect from the tool's response.
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, so the baseline is 3. The description adds value by providing concrete examples for the path parameter ('/nf-instances') and schema parameter ('NFProfile'), and by explaining the intended workflow for spec_id and api_name (use list_openapi to discover). This goes beyond the schema's structural descriptions, though it does not cover offset or max_lines.
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 OpenAPI definition content for 5G service-based interface APIs (TS 29.xxx series).' It distinguishes from siblings like list_openapi by specifying that it retrieves actual definition content, not just listing available APIs. The mention of looking up HTTP request/response details, paths, and schemas further clarifies the specific resource and action.
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 explicitly advises to 'Use list_openapi first to discover available API names,' providing a clear prerequisite and directing to an alternative tool. It also gives specific usage guidance for parameters: 'Use the path parameter to filter by API endpoint (e.g. /nf-instances) or the schema parameter to filter by data type (e.g. NFProfile).' This tells the user exactly when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cross-references between 3GPP specifications and RFCs.
Directions:
outgoing (default): Find all specs/RFCs referenced by a given section. Requires spec_id and section_number. Use include_subsections to also gather refs from child sections.
incoming: Find all sections that reference a given spec (and optionally a specific section). Requires spec_id. section_number is optional.
Returns structured reference data including target spec, section, title (if available in DB), and context snippet. Responses are capped at 500 references; a separate notice reports the total, and offset pages through the rest.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of references to skip, for paging past a truncated response (default: 0) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| direction | No | outgoing (default): references FROM this section to other specs. incoming: references TO this spec/section from other specs. | |
| section_number | No | Section number (e.g. 5.1.2). Required for outgoing direction. | |
| include_subsections | No | Include subsections when collecting outgoing references (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral disclosure. It reveals the 500-reference cap, pagination via offset, and that responses include structured data plus a total-count notice. It does not mention rate limits or authorization, but those are not critical for a read-only lookup tool.
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 well-structured with clear sections for each direction, uses bullet-style formatting for readability, and every sentence adds essential guidance. No fluff or redundancy.
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 (5 parameters, two modes), the description covers all necessary details: parameter requirements per mode, default behaviors, response structure, pagination limit, and output format. Without an output schema, it still describes the return data adequately.
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 coverage is 100%, so the baseline is 3. However, the description adds semantic value beyond the schema by explaining parameter roles in context (e.g., section_number is required for outgoing, optional for incoming) and linking params to use cases (include_subsections only relevant for outgoing).
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: finding cross-references between 3GPP specs and RFCs. It distinguishes two modes (outgoing and incoming) with specific resource targets (specs, RFCs, sections), and the sibling context shows no other tool overlaps with this function.
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 explicitly explains when to use outgoing vs incoming direction, lists required vs optional parameters for each, and notes a default behavior ('outgoing (default)'). It also mentions a cap of 500 references with pagination, guiding the agent on handling large result sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the markdown content of a specific section in a 3GPP specification. This tool is for reading specification document text (architecture, procedures, requirements). For API details such as HTTP request/response bodies, paths, and data models of 5G service-based interfaces (TS 29.xxx series), use get_openapi instead. Specify the section number with the section_number parameter (e.g. 5.1.2). Figures appear as  links; fetch one with get_image and that NAME. Formulas are LaTeX: a standalone equation is a ```latex code block (its equation number kept as \tag{7.3-1}), and a formula inside a sentence or a table cell is delimited with $...$, or $$...$$ when the source sets it as a display equation. Pass version to read a past version, which is downloaded and converted on first use; call list_versions first to see which versions exist. Large sections are paginated (default 200 lines). Use offset and max_lines to navigate.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Start line number (0-based, default: 0) | |
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. | |
| max_chars | No | Maximum number of characters to return (can be combined with max_lines) | |
| max_lines | No | Maximum number of lines to return (default: 200) | |
| section_number | Yes | required,Section number to retrieve (e.g. 5.1.2) | |
| include_subsections | No | Include all subsections (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It transparently explains how figures appear as `` links and how to fetch them with `get_image`, details LaTeX formula formatting (standalone vs. inline), describes version handling (first-use download/conversion), and reveals pagination behavior (default 200 lines). It does not cover error cases or what happens for invalid sections, but the behavioral disclosure is rich and helpful.
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 paragraph of ~150 words, dense but well-organized. It front-loads the core purpose and sibling distinction, then covers output format, version handling, and pagination. While it could benefit from bullet points or more whitespace for scanning, every sentence adds value and there is no repetition. It is concise for the amount of information conveyed.
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 7 parameters, 2 required, no output schema, and no annotations, the description covers purpose, usage alternatives, output format (figures, formulas), version behavior, and pagination. It does not describe error handling (e.g., invalid section/spec) or the exact structure of the return value, but it provides enough context for an agent to use the tool effectively in most scenarios.
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 coverage is 100% (all 7 parameters have descriptions), so baseline is 3. The description adds extra meaning beyond the schema: e.g., for `section_number` it gives an example ('5.1.2'), for `version` it explains the first-use download behavior, and for `offset`/`max_lines` it contextualizes pagination. This additional context improves 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: 'Get the markdown content of a specific section in a 3GPP specification.' It also specifies the type of content (architecture, procedures, requirements) and explicitly distinguishes from the sibling tool `get_openapi` for API details. The verb 'get' and resource 'section' are specific and unambiguous.
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 direct guidance on when to use this tool vs. `get_openapi` for API details. It advises to call `list_versions` first to check available versions and explains pagination with offset and max_lines. This explicit context helps the agent choose the correct tool and navigate parameters effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the table of contents (section structure) of a 3GPP specification. Pass version to see the structure of a past version, which is downloaded and converted on first use; section numbers often move between releases, so check the table of contents before reading a section of an older version.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals that passing a 'version' triggers a download and conversion on first use, and notes that section numbers often change between releases. These are important behavioral traits. However, it does not state whether the operation is read-only or whether it has any side effects beyond the initial conversion (e.g., caching behavior). The transparency is good but not exhaustive.
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 two sentences long, with no wasted words. The first sentence defines the core purpose, and the second sentence adds targeted usage guidance and a behavioral note. Every sentence serves a clear function, and the structure is front-loaded with the most important 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 simplicity (2 parameters, no output schema), the description is nearly complete. It explains what the tool does, the version behavior, and a typical use case. It could be improved by briefly describing the return format (e.g., list of section numbers and titles), but the phrase 'section structure' provides enough context for an agent to infer the output. The absence of an output schema increases the value of a description, and this one is sufficient but not exhaustive.
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 baseline is 3. The tool description adds minimal parameter-specific meaning beyond what the schema already provides. It mentions the 'version' parameter's purpose ('see the structure of a past version') and the conversion note, but the schema already describes the parameter's accepted formats and defaults. The description does not enrich the semantics of 'spec_id' beyond what is obvious.
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 verb ('Get') and resource ('table of contents (section structure) of a 3GPP specification'). It distinguishes the purpose from siblings like 'get_section' (which reads a specific section) and 'list_versions' (which lists versions). The phrase 'check the table of contents before reading a section' further clarifies its role relative to sibling 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 clear usage context: use this tool to inspect the section structure, especially before reading an older version. It warns that section numbers move between releases, implying when to use this tool over others. While it does not explicitly name alternative tools (e.g., 'get_section'), the guidance is direct and actionable. The version parameter description (in schema) adds additional hints like using 'list_versions', which compensates slightly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List embedded images in a 3GPP specification. Returns image names, MIME types, and whether they are viewable by LLMs. Use get_image to retrieve a specific image. Pass version to list a past version's images; the images of an archived version are downloaded on first use, which takes up to a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) | |
| version | No | Specification version to read (e.g. 18.6.0). Also accepts an archive token (i60) or a release selector (Rel-18). Defaults to the version in the database. Use list_versions to see what exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits such as the latency for archived versions ('takes up to a few minutes') and the defaulting behavior of the version parameter. No annotations are provided, so the description carries the full burden and does so effectively, though it could mention if the list is paginated or has size limits.
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 concise (three sentences) and well-structured, with the main action upfront, followed by sibling tool reference, and version handling details. Every sentence adds value with no redundancy.
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 only 2 parameters with full schema descriptions and no output schema, the description covers usage context well. It explains the version parameter's behavior and an edge case (archived version latency). A minor gap is not stating whether the returned list is complete or paginated, but overall it is sufficient for an agent to use the tool correctly.
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 provides 100% coverage with descriptions for both parameters, so the baseline is 3. The description adds useful context for the 'version' parameter (e.g., about archive tokens and release selectors) beyond the schema's brief note, but does not add new info for 'spec_id'.
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 action ('List embedded images in a 3GPP specification') and specifies what it returns ('image names, MIME types, and whether they are viewable by LLMs'). It distinguishes itself from sibling tools like 'get_image' by noting that 'list_images' lists images while 'get_image' retrieves a specific one.
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 clear guidance on when to use this tool vs alternatives: 'Use get_image to retrieve a specific image.' It also explains how to handle versions, including past archived versions that may have a delay. However, it does not explicitly mention when not to use it or other exclusions beyond the sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available OpenAPI definitions from 3GPP specifications (TS 29.xxx series). Use this to discover API names before calling get_openapi. Optionally filter by spec ID.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | No | Filter by specification ID (e.g. TS 29.510) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the basic action (listing definitions) and optional filtering, but does not disclose any behavioral traits such as return format, pagination, authentication requirements, or performance implications. For a simple read-only list tool, this is minimally adequate but lacks depth.
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 consists of two concise sentences. The first sentence defines the action and resource; the second provides usage context and an optional filter. Every phrase earns its place, with no redundancy or unnecessary detail.
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 low complexity (one optional parameter, no output schema), the description is mostly complete. It links usage to get_openapi and mentions filtering. However, it does not explain the return data shape (e.g., list of API names) or differentiate from other sibling tools like list_specs or search_openapi. Slight room for improvement.
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 coverage is 100% (the single parameter spec_id has a schema description). The description adds 'Optionally filter by spec ID,' which mirrors the schema. Since the schema already documents the parameter fully, the description adds minimal extra meaning, meeting the baseline for high coverage.
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 'List available OpenAPI definitions from 3GPP specifications (TS 29.xxx series).' It uses a specific verb ('list') and resource ('OpenAPI definitions'), and distinguishes from siblings like get_openapi (which gets a specific definition) and list_specs (which lists specs). The context 'discover API names before calling get_openapi' further clarifies its role.
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 explicitly tells when to use the tool: 'Use this to discover API names before calling get_openapi.' It also mentions optional filtering by spec ID. While it does not explicitly state when not to use it or list alternatives (e.g., list_specs), the guidance is clear and contextually useful for an AI agent.
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. Optionally filter by series number and/or by an ID prefix (query). Results are paginated (default 20 per page); use limit and offset to navigate.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 20) | |
| query | No | Filter specs whose ID starts with this text (e.g. '38.21' matches 38.211, 38.212, 38.213) | |
| offset | No | Number of results to skip for pagination (default: 0) | |
| series | No | Filter by series number (e.g. 23 for TS 23.xxx) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It adds pagination defaults and filter semantics beyond the schema, but does not mention authentication needs, output format, error behavior, or rate limits—leaving significant gaps for a tool with no annotations.
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?
Two efficient sentences: first states purpose, second covers filtering and pagination. No wordiness, front-loaded key 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?
For a listing tool with 4 optional parameters and no output schema, the description explains filters and pagination adequately but omits what the response looks like (e.g., fields returned, ordering). Without output schema, the description should hint at the return structure to be fully complete.
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 coverage is 100%, so baseline is 3. The description adds context that filters can be combined and how pagination works (limit/offset navigation), but most parameter meaning is already clear from schema descriptions. The added value is modest.
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 verb "List" and the resource "available 3GPP specifications." It mentions optional filtering by series and ID prefix, plus pagination—fully distinguishing this from sibling tools that list images, OpenAPI specs, or versions.
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 explains optional filtering and pagination, so the agent knows how to use it. However, it does not provide any guidance on when NOT to use this tool vs. alternatives (e.g., search, get_section), missing the opportunity to prevent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the versions of a 3GPP specification, newest first.
Each entry reports where the version can be read from:
database: in the prebuilt database, covered by search, images and cross-references
cached: fetched on demand earlier, available immediately
archive: exists upstream; reading it downloads and converts it first, which takes up to a few minutes for a large specification
Pass a version from this list to get_section or get_toc to read a past version.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_id | Yes | required,Specification ID (e.g. TS 23.501) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses behavioral traits: newest-first order, the meaning of three statuses (database, cached, archive), and time cost for archive versions. No contradictions exist.
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 well-structured with a clear purpose sentence, bulleted details, and a usage recommendation. It is concise with no redundant information, though slightly more compacting is possible.
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?
Despite having no output schema, the description fully explains the output (list of versions with status meanings) and connects to sibling tools, making the tool's usage context complete.
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 coverage is 100% and the description adds no meaning beyond the schema's own parameter description ('Specification ID (e.g. TS 23.501)'). Baseline of 3 is appropriate.
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 explicitly states 'List the versions of a 3GPP specification, newest first' – a specific verb and resource that clearly distinguishes from sibling tools like list_specs (list specifications) and list_images (list images).
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 explicit context for use: 'Pass a version from this list to get_section or get_toc to read a past version.' This guides when to use the tool, but does not explicitly exclude scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across 3GPP specifications using SQLite FTS5 syntax.
Query syntax:
AND/OR/NOT: AMF AND authentication
Phrase: "service based interface"
Prefix: handov*
Column filter: title:authentication or content:handover
Proximity: NEAR(AMF UE, 5)
Hyphenated or dotted terms (e.g. IMS-AKA, sec-agree, 38.101) are auto-quoted to avoid FTS5 syntax errors.
After a positive term, "-term" excludes that term (e.g. AMF -SMF), same as NOT. An exclusion cannot begin a query or immediately follow AND/OR.
Stemming:
The index uses porter stemming: inflected English forms match each other (handover finds handovers).
Prefix and phrase queries operate on stemmed forms, so they can match a bit more broadly than the exact surface text.
Pagination:
Results come as {results, total_count, limit, offset}; total_count is the full match count.
Use limit (default 10, max 200) and offset to page through matches beyond the first page.
Tips:
Use exact 3GPP terms (AMF, SMF, gNB, UE, NRF, PCF, etc.)
Phrase search improves precision for multi-word concepts
title:term restricts matches to section headings only
Use spec_ids to search across multiple specifications at once
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results per page (default: 10, max: 200) | |
| query | Yes | required,FTS5 query string. Hyphenated or dotted terms like IMS-AKA and 38.101 are auto-quoted. Use AND/OR/NOT operators and double-quoted phrases for exact matches (e.g. '"core network" AND AMF'). | |
| offset | No | Number of results to skip for pagination (default: 0). Combine with total_count in the response to page through all matches. | |
| spec_id | No | Limit search to a single specification (e.g. TS 23.501). Ignored when spec_ids is provided. | |
| spec_ids | No | Limit search to one or more specifications (e.g. ["TS 23.501", "TS 23.502"]). Takes precedence over spec_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given there are no annotations, the description carries full burden for behavioral disclosure. It explicitly states key behaviors: auto-quoting of hyphenated/dotted terms, exclusion syntax, porter stemming, pagination with total_count, and the precedence of spec_ids over spec_id. This is comprehensive beyond what the schema reveals.
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 structured with clear sections (Query syntax, Stemming, Pagination, Tips) and is well organized. It earns its length given the complexity of FTS5 syntax, but could be slightly more concise in the exclusion rules section, which repeats some details from the syntax list.
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?
The description covers query syntax, stemming, pagination, and provides domain tips. There is no output schema, but the response structure is described inline (results, total_count, limit, offset). The description is complete for a search tool of this complexity. Minor gap: it does not explain what happens on an empty query or FTS5 syntax errors beyond auto-quoting.
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 baseline is 3. The description does add value for some parameters (e.g., explaining spec_ids precedence over spec_id, and specifying default/max for limit), but mostly the query syntax details are an extension of the 'query' parameter's natural behavior rather than new parameter-specific semantics. The description does not add meaning significantly beyond the schema.
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 begins with a clear verb and resource: 'Full-text search across 3GPP specifications'. It specifies the technology (SQLite FTS5 syntax), and the query examples clearly differentiate it from sibling tools like search_openapi or list_specs. The purpose is specific and distinct.
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 extensive query syntax and tips for effective search (tips on exact terms, phrase search, column filters), but it does not explicitly state when to use this tool versus alternatives like search_openapi or get_section. There is no 'when-not-to-use' guidance. Usage is implied through examples and tips but not formally defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across the OpenAPI definitions of the 5G service-based interface APIs (TS 29.xxx series), using SQLite FTS5 syntax.
Use this when you need an API detail but do not know which API document holds it — searching for a data type (NFProfile, SmContextCreateData) or an endpoint (/nf-instances, subscriptions) finds it without guessing an api_name first. When you already know the document, get_openapi reads it directly.
This is a separate index from the search tool: search covers specification clause text and never returns OpenAPI content, and this tool covers OpenAPI content only.
Results:
One hit is one definition, not one document: either a schema (a data type from components.schemas) or an operation (one HTTP method of one path, named like "PUT /nf-instances/{nfInstanceID}").
A query that is a single bare term ranks a definition of exactly that name first, so searching NFProfile returns the NFProfile schema itself ahead of the schemas that merely reference it.
Each hit reports spec_id, api_name, kind, name and a snippet. Pass those to get_openapi (with its schema or path parameter) to read the full definition.
A schema's text carries one level of $ref expansion, so referenced field names are searchable, but a type two hops away is not. Follow it up with get_openapi.
Set include_body to get the matched definition's full text inline. It is much larger than a snippet.
Query syntax:
AND/OR/NOT: NFProfile AND heartbeat
Phrase: "nf instances"
Prefix: subscri*
Column filter: name:NFProfile or body:nfInstanceId or api_name:Nnrf_NFManagement
Hyphenated, dotted or underscored terms (e.g. nf-instances, 29.510, Nnrf_NFManagement) are auto-quoted to avoid FTS5 syntax errors.
Tokenization:
Unlike search, this index applies no stemming: identifiers are matched as written, and inflected English forms do not fold together.
'-', '.' and '_' split tokens, so Nnrf_NFManagement is indexed as "nnrf" and "nfmanagement" and /nf-instances as "nf" and "instances" — a partial name matches, but camelCase is not split (supportedFeatures is one token).
Pagination:
Results come as {results, total_count, limit, offset}; total_count is the full match count.
Use limit (default 10, max 200) and offset to page through matches beyond the first page.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Limit the search to one kind of definition: "schema" for data types or "operation" for endpoints. Both are searched when omitted. | |
| limit | No | Maximum number of results per page (default: 10, max: 200) | |
| query | Yes | required,FTS5 query string. Hyphenated or dotted terms like nf-instances and 29.510 are auto-quoted. Use AND/OR/NOT operators and double-quoted phrases for exact matches. | |
| offset | No | Number of results to skip for pagination (default: 0). Combine with total_count in the response to page through all matches. | |
| api_name | No | Limit the search to a single API document (e.g. Nnrf_NFManagement). Use list_openapi to see the available names. | |
| spec_ids | No | Limit the search to one or more specifications (e.g. ["TS 29.510", "TS 29.518"]). | |
| include_body | No | Return the full text of each matching definition instead of a snippet (default: false). Costs many more tokens; prefer the default and follow up with get_openapi. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It comprehensively discloses behavior: result granularity (one definition per hit), ranking (exact name matches first), $ref expansion depth, include_body effect, query syntax (including auto-quoting for special characters), tokenization rules (no stemming, split on hyphens/dots/underscores, no camelCase split), and pagination details. No contradictory or missing behavioral traits.
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 well-structured with sections (Results, Query syntax, Tokenization, Pagination) and front-loaded with the main purpose. While it is long, every sentence provides necessary information given the tool's complexity. It could be slightly more concise, but it earns its length.
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 complexity (7 parameters, no output schema, multiple sibling tools), the description is complete. It explains the result structure, how to follow up with get_openapi, the difference from search, tokenization idiosyncrasies, and pagination. It addresses all likely agent questions.
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%, but the description adds substantial value beyond the schema. It explains the query syntax in detail (operators, phrases, column filters, auto-quoting), the purpose and cost of include_body, how pagination uses limit/offset with total_count, and the meaning of kind (schema vs operation). The description makes the parameters much more usable.
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?
Clearly states the tool performs full-text search on OpenAPI definitions of 5G APIs, using SQLite FTS5 syntax. It distinguishes from sibling tools by explicitly contrasting with 'search' (covers clause text, not OpenAPI) and 'get_openapi' (for when the document is already known).
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?
Provides explicit guidance: 'Use this when you need an API detail but do not know which API document holds it.' It also gives a clear alternative: 'When you already know the document, get_openapi reads it directly.' Additionally, it contrasts with the sibling 'search' tool, specifying that search covers different content.
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.
v0.1.0compare_versionsget_asn1get_imageget_openapiget_referencesget_sectionget_toclist_imageslist_openapilist_specslist_versionssearchsearch_openapiScored across 13 tools
Every tool targets a distinct content type or operation: listing vs. retrieval, specification text vs. ASN.1 vs. OpenAPI vs. images vs. cross-references. The two search tools explicitly separate specification clauses from OpenAPI definitions, eliminating ambiguity.
All tools use a consistent lowercase snake_case convention with a verb-noun pattern (list_*, get_*, search_*, compare_versions). No mixed conventions or irregular names, making it easy to infer functionality from the name.
13 tools is a well-scoped set for a specification retrieval system. Each tool adds a distinct capability—discovery, reading, searching, comparison, images, ASN.1, OpenAPI, references—without redundancy or bloat.
The tool surface covers the full lifecycle of read-only specification access: discovery (list_specs, list_versions, list_openapi, list_images), retrieval (get_section, get_image, get_asn1, get_openapi), searching (search, search_openapi), comparison (compare_versions), and cross-references (get_references). No obvious gaps for the stated domain.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
3GPP Scout connects Cursor, Claude, Codex and other MCP clients to a hosted, continuously updated 3GPP search service. Search TS/TR specifications across Rel-15 through Rel-20, retrieve cited clauses, and search text, diagrams and figures. Explore recent RAN1, RAN2, RAN3, RAN4 and SA2 TDocs, company proposals and extracted meeting decisions, with source links. Connect using Streamable HTTP at https://api.3gppscout.com/mcp/ and sign in with OAuth 2.1. No local index or API key in the MCP configuration is required. Explorer includes 150 API/MCP requests per month; Founding Engineer includes 1,000 for $8/month. Hosted Scout chat is billed separately. 3GPP Scout is an independent product and is not affiliated with, endorsed or sponsored by 3GPP, ETSI or any 3GPP Organizational Partner. 3GPP™ is a trade mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. Excerpts are quoted for reference and the official documents govern. Copyright, correction or removal requests: contact@3gppscout.com.
