Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ETSI Standards Connector Ingest ETSI TS 103 720 and summarize its mandatory video codec profiles."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that fetches, parses, and summarises ETSI telecommunications and media standards documents using Claude. Once registered, Claude can autonomously look up and ingest standards mid-conversation, then use the resulting summaries to answer questions, write conformant XML, or generate code that meets a specification.
You: "Does ETSI TS 102 818 define a required XML namespace?"
Claude --> search_standard("ETSI TS 102 818")
--> ingest_standard("ETSI TS 102 818") [downloads PDF, summarises with Claude Opus]
--> reads standards/TS-102-818.md
--> "Yes. Clause 5.2 [M] requires the namespace..."The pipeline has three stages:
1. Search — queries the ETSI standards search API to find the current version of a standard and its PDF download URL.
2. Ingest — downloads the PDF, extracts the text, and calls Claude Opus to produce a structured summary. The summary captures all mandatory/optional requirements, data structures, workflows, allowed values, and normative references. It is written to standards/<id>.md and cached for future use.
3. Query — any subsequent question, code generation, or XML output task reads the local summary rather than the PDF, keeping token costs low.
Related MCP server: mcp-server-3gpp
Tool | Description |
| Search the ETSI catalogue by standard number or keywords. Returns up to 20 matches sorted most-recent first. |
| Download and parse an ETSI standard PDF. Returns the document text and summarisation instructions to Claude, which then produces the summary and calls |
| Persist a summary to |
| Read a summary that has already been ingested. |
| List all standards that have been summarised locally. |
A resource template standards://{id} also exposes summaries directly as MCP resources.
Every standards/<id>.md follows a fixed schema designed to be token-efficient and machine-readable:
Scope — what the standard covers
Key Concepts — terms with definitions
Normative References — other standards required for conformance
Data Structures — fields, types, allowed values; binary structures include byte offsets and hex values
Rules and Constraints — numbered list, each prefixed [M] (mandatory) or [O] (optional); recommended values marked *
Workflows and Sequences — numbered steps or Mermaid diagrams
Conformance Requirements — all SHALL / SHOULD / MAY clauses
Related Standards — standards that may warrant further ingestion
Node.js 20 or later
No Anthropic API key is required in the MCP server. Summarisation is performed by the Claude instance that is already running (Claude Code or Claude Desktop) — the server only handles fetching and parsing.
git clone <repo>
cd claude-etsi-connector
npm install
npm run buildclaude mcp add --scope user etsi -- node /absolute/path/to/claude-etsi-connector/dist/src/server.jsThis writes to ~/.claude.json. No API key configuration is needed.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"etsi": {
"command": "node",
"args": ["/absolute/path/to/claude-etsi-connector/dist/src/server.js"]
}
}
}Restart Claude Desktop after saving.
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}' \
| node dist/server.jsYou should see a JSON response containing "name":"etsi-connector".
Variable | Default | Description |
|
| Where summary |
|
| Where downloaded PDFs are cached. |
Once registered, Claude can use the tools directly. You can also prompt it explicitly:
"Ingest ETSI TS 103 720 and tell me what video codec profiles are mandatory."
"Using the summary for TS 102 818, write a valid XML service information document."
"What standards does TS 102 818 normatively reference that haven't been ingested yet?"
claude-etsi-connector/
├── src/
│ ├── server.ts # MCP server — tool and resource registration
│ ├── fetcher.ts # ETSI search API + PDF download
│ ├── parser.ts # PDF text extraction
│ ├── summariser.ts # Claude API call → standards/<id>.md
│ └── config.ts # Paths and model constants
├── prompts/
│ └── summarise.md # Summarisation prompt template
├── standards/ # Generated summaries (committed to git)
├── cache/ # Downloaded PDFs (git-ignored)
└── dist/ # Compiled output (git-ignored)Summarisation calls claude-opus-4-6 and may take 30–90 seconds for a long specification.
Very large documents (>150,000 characters of extracted text, roughly 300+ pages) are truncated. The summary will note where truncation occurred.
PDF text extraction quality depends on how the PDF was produced. Scanned or image-based PDFs will yield poor results.
The ETSI search API does not reliably flag superseded versions; the connector always takes the first (most recent) result.
Fetch and parse an ETSI standard PDF. Saves the document text locally and returns summarisation instructions and metadata. Then call read_document_text repeatedly to read the document in chunks, build the summary, and finally call save_summary to persist it. If the standard is already ingested, returns the existing summary immediately. Use refresh=true to re-fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Standard number to fetch, e.g. 'ETSI TS 102 818' | |
| refresh | No | Re-fetch and re-summarise even if a summary already exists (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: saves text locally, returns summary/metadata, and immediate return for cached standards. However, it does not mention potential side effects of refresh (overwriting) or any authorization needed.
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 (4 sentences) and well-structured: action, subsequent steps, caching behavior, refresh option. Every sentence provides essential information without 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 complexity (multi-step process, caching), the description is comprehensive. It covers the workflow and restart for already ingested standards. Lacks exact details of returned metadata format, but the sibling tools fill gaps. No output schema, but the description adequately conveys return type.
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%, but the description adds meaningful context beyond the schema: it clarifies 'query' is a standard number with an example, and 'refresh' triggers re-fetch even if summary exists. This helps the agent understand usage intent.
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 fetches and parses an ETSI standard PDF, saves text locally, and returns summary instructions and metadata. It explicitly distinguishes from sibling tools like read_document_text and save_summary by indicating they are subsequent steps.
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 guidance on when to use the tool: for new ingestion or refresh. It outlines the required subsequent steps (call read_document_text, then save_summary) and explains the cached behavior (returns existing summary if already ingested). The refresh parameter is clearly documented.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the stored summary for an already-ingested ETSI standard.
| Name | Required | Description | Default |
|---|---|---|---|
| standard_id | Yes | Standard ID as stored, e.g. 'TS-102-818' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose what happens if standard not ingested, return format, or side effects. Minimal behavioral info beyond read-only nature inferred from verb.
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?
Single sentence that efficiently conveys purpose and key constraint. Every word earns its place. Front-loaded and clear.
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?
Simple tool with 1 param and no output schema. Description covers purpose and pre-condition (already-ingested). Missing: behavior when summary doesn't exist, return format. Adequate but not thorough.
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?
Single parameter 'standard_id' is fully described in schema with example. Description adds no extra semantic value beyond schema. Baseline score of 3 applies as schema coverage is 100%.
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?
Description clearly states verb 'Read', resource 'stored summary', and context 'already-ingested ETSI standard'. It distinguishes from sibling tools like save_summary (write) and fetch_standard (different resource).
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?
Implies that the standard must already be ingested ('already-ingested'), but no explicit guidance on when to use this vs alternatives like read_document_text for full text. Lacks exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ETSI standards that have been ingested and summarised locally.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and description lacks details on pagination, read-only behavior, or output structure.
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?
Single concise sentence front-loading the action with no unnecessary words.
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?
Lacks output format details, but acceptable for a simple list tool with no schema or annotations.
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?
No parameters exist, so description doesn't need to add parameter info; baseline for 0 params is 4.
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 it lists all ingested ETSI standards, distinguishing it from siblings like fetch_standard or search_standard.
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?
No explicit guidance on when to use vs alternatives, but the purpose is clear enough to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a chunk of the extracted text for a standard fetched with fetch_standard. Call repeatedly with the returned next_offset until done is true.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | Yes | Character offset to read from (start with 0) | |
| standard_id | Yes | Standard ID returned by fetch_standard, e.g. 'TS-102-818' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses pagination behavior (offset, next_offset, done) and implies a read-only operation. Lacks explicit safety/permission info but is adequate.
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 concise sentences: first defines purpose, second provides usage pattern. No wasted words, front-loaded with 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?
Given no output schema, the description sufficiently explains return values (next_offset, done). Minor gaps: no mention of error handling or text format, but overall adequate for usage.
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%, baseline 3. The description adds crucial usage semantics: explains pagination pattern with next_offset and done, which is beyond schema definition. No output schema, so description compensates effectively.
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 'Read' and the resource 'chunk of the extracted text for a standard', which distinguishes it from siblings like fetch_standard or get_summary. It specifies the context of use.
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 (after fetch_standard) and how to use repeatedly with next_offset. It does not explicitly exclude alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a structured summary to standards/.md. Call this after producing a summary from fetch_standard output.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | The complete markdown summary text to save | |
| standard_id | Yes | Standard ID returned by fetch_standard, e.g. 'TS-102-818' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states 'persist'' without details on overwrite behavior, authentication needs, or side effects. This is insufficient for a mutation 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 two short sentences, each adding essential information. The first states the core action, the second provides usage context. No redundancy or extra words.
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, no annotations) and sibling context, the description adequately covers the purpose and workflow. Missing behavioral details slightly reduce completeness, but it's still sufficient for typical use.
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 already provides 100% coverage with descriptions for both parameters. The tool description adds no additional semantic meaning beyond the schema, so the baseline score of 3 applies.
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 persists a structured summary to a specific file path (standards/<id>.md) and distinguishes it from siblings like fetch_standard and get_summary by specifying the action and context.
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 says 'Call this after producing a summary from fetch_standard output,' providing clear when-to-use guidance. It doesn't mention when not to use or alternatives, but the context is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the ETSI standards catalogue. Returns matching standards sorted most-recent first.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Standard number or keywords, e.g. 'ETSI TS 102 818' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses sorting order (most-recent first) but omits other behaviors like result format, pagination, error handling, or rate limits. For a search tool, more detail on output structure would be beneficial.
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 concise sentences, front-loaded with purpose and key behavior (sorting). 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 low complexity (one param, no output schema, no nested objects), the description is adequate but not complete. It mentions return order but not result structure, limits, or how to paginate. Missing details could leave the agent uncertain about the output format.
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?
Only one parameter 'query' with schema description 'Standard number or keywords, e.g. 'ETSI TS 102 818''. The description adds a helpful example, providing clarity beyond the schema. Schema coverage is 100%, so baseline is 3, but the example elevates it.
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?
Description clearly states it searches the ETSI standards catalogue and returns matching standards sorted most-recent first. Verb is specific ('search') and resource is identified ('ETSI standards catalogue'). Distinguishes from siblings like fetch_standard and get_summary which are for individual 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?
Implied usage: use when needing to find standards by query. No explicit guidance on when not to use or alternatives. Sibling tools are listed but no comparison provided, leaving the agent to infer based on names.
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. Dates show when Glama detected each change.
v0.1.0fetch_standardget_summarylist_ingestedread_document_textsave_summarysearch_standardEach tool has a clearly distinct purpose: fetch_standard (fetch and parse), get_summary (retrieve summary), list_ingested (list ingested standards), read_document_text (read chunks), save_summary (persist summary), search_standard (search catalogue). No overlap or ambiguity.
All tool names follow the verb_noun pattern with snake_case (e.g., fetch_standard, get_summary). Consistent and predictable naming throughout.
6 tools is well-scoped for an ETSI standards ingestion and summarization system. Each tool covers a necessary step without redundancy or excess.
Core workflows (fetch, read, summarize, retrieve, search, list) are covered. Minor gap: no tool to delete an ingested standard, but this is a non-critical omission for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
AI reasoning checks any document against known international standards before your agent acts on it.
Exact IBAN, VAT, cron, regex answers; HTML/URL to hosted PDF or screenshot; agent memory; workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/magicbadger/claude-mcp-etsi'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
