iana-registries-mcp-server

Read IANA registry records

iana_get_registry_records

Read-onlyIdempotent

Read records from any IANA XML registry by id, e.g. registry "tls-parameters" with subregistry "tls-parameters-4" (TLS Cipher Suites), "protocol-numbers", "http-methods", or "cbor-tags"; an iana.org/assignments URL also works. Filter with value (exact match on the key column, or on the column field names; digits compare by number with a cell of digits ("0443" finds "443") and one 0x token with a one-token 0x cell ("0x5" finds "0x05"), each also matching its own kind of range row ("105-199", "0x11-0xff"); other 0x forms compare their digits as written, in any comma, space, or brace spelling) and contains (words in any field; records with a field equal to the words come first). When a registry has several sub-registries and none is given, the response lists them instead of records; a table that nests tables lists them too. Field names are the registry's XML element names (e.g. "rec" is the Recommended column). Large registries page through cursor. Find ids with iana_search_registries.

Input Schema

Name	Required	Description
`field`	No	Column for value to match instead of the key column, case-insensitive, one of the names in columns: e.g. "type" for a DNS RR type mnemonic, or "name" for every row of a service name. Ignored without value.
`limit`	No	Requested maximum results, 1–1,000,000; values above 100 are clamped to 100 and disclosed as requested_limit and effective_limit. Default 25.
`value`	No	Exact match on the key column named by value_field (value, else number, else the first column), or on field when set; case and whitespace are ignored. A value of digits compares exactly with a cell of digits, so "0443" finds "443", and also matches decimal range rows without precision loss, including 64-bit endpoints; it never matches a 0x cell. One 0x token compares by number with a one-token 0x cell, so "0x5" finds "0x05", and also matches range rows such as "0x11-0xff". Any other pair of 0x forms compares the digits as written: "0x1301", "{0x13,0x01}", and "0x13 0x01" all find "0x13,0x01", while "0x13" never finds "0x00,0x13".
`cursor`	No	next_cursor from the previous page; reuse it only with the same registry, subregistry, value, field, and contains.
`contains`	No	Words matched as whole tokens against every field and reference id, e.g. "chacha20". Records with a field equal to the words come first.
`registry`	Yes	Registry id, e.g. "tls-parameters", or its https://www.iana.org/assignments/<id> URL (a #fragment selects the sub-registry when subregistry is unset).
`subregistry`	No	Sub-registry id, case-insensitive, e.g. "tls-parameters-4". Omit to read the only sub-registry, or to list them when there are several.

Output Schema

Name	Required	Description
`cap`	No	The limit applied.
`error`	No	Present when the call failed. Absent on success.
`notes`	No	Notes of the table read (of the registry, when listing), first page only. With registry_notes: the first 25 and 4,000 characters at most, these first.
`shown`	No	Results returned.
`notice`	No	Guidance on a miss, a cut list, or another condition.
`offset`	No	Matching records before this page, on pages after the first.
`source`	No	Provenance and freshness of the answer.
`columns`	No	Field (XML element) names seen, first-seen order, the first 50.
`records`	No	Records in registry order (with contains, records with a field equal to the words first), up to limit and a 48,000-character page budget.
`truncated`	No	True when more matches exist than were returned.
`references`	No	The documents that define the table read, the first 25.
`totalCount`	No	Matches before the limit was applied.
`description`	No	Description of the table read, or of the registry when listing; a YANG module registry names its module file here. At most 2,000 characters.
`next_cursor`	No	Pass as cursor, with the same filters, for the next page.
`registry_id`	No	Registry id.
`value_field`	No	The table's key column: each record's value comes from it, and the value filter matches it unless field names another.
`subregistries`	No	Tables to read next, the first 250: every sub-registry when one must be chosen (records is then empty), or the tables nested directly in the table read, on its first page.
`registry_notes`	No	The registry root's notes and footnotes, on the first page of a sub-registry read; records cite them by anchor. Shares the notes caps, after notes.
`registry_title`	No	Registry title.
`subregistry_id`	No	Id of the sub-registry the records come from.
`effective_limit`	No	The response limit after clamping, present when clamped.
`notes_truncated`	No	True when notes or registry_notes were cut at 4,000 characters.
`requested_limit`	No	The requested limit, present when clamped.
`subregistry_title`	No	Title of that sub-registry.
`registration_ranges`	No	Allocation ranges, when the table defines them: the first 25, each text at most 2,000 characters.
`registration_procedure`	No	Registration rule of the table read, or of the registry when listing; at most 2,000 characters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 17, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum number of results to return, 1–100. Default 25."New value: +"Requested maximum results, 1–1,000,000; values above 100 are clamped to 100 and disclosed as requested_limit and effective_limit. Default 25."

changedInput schema / properties / limit / maximum
```
Previous value: -100New value: +1000000
```

changedInput schema / properties / value / description

Previous value: -"Exact match on the key column named by value_field (value, else number, else the first column), or on field when set; case and whitespace are ignored. A value of digits compares by number with a cell of digits, so \"0443\" finds \"443\", and also matches range rows such as \"105-199\"; it never matches a 0x cell. One 0x token compares by number with a one-token 0x cell, so \"0x5\" finds \"0x05\", and also matches range rows such as \"0x11-0xff\". Any other pair of 0x forms compares the digits as written: \"0x1301\", \"{0x13,0x01}\", and \"0x13 0x01\" all find \"0x13,0x01\", while \"0x13\" never finds \"0x00,0x13\"."New value: +"Exact match on the key column named by value_field (value, else number, else the first column), or on field when set; case and whitespace are ignored. A value of digits compares exactly with a cell of digits, so \"0443\" finds \"443\", and also matches decimal range rows without precision loss, including 64-bit endpoints; it never matches a 0x cell. One 0x token compares by number with a one-token 0x cell, so \"0x5\" finds \"0x05\", and also matches range rows such as \"0x11-0xff\". Any other pair of 0x forms compares the digits as written: \"0x1301\", \"{0x13,0x01}\", and \"0x13 0x01\" all find \"0x13,0x01\", while \"0x13\" never finds \"0x00,0x13\"."

addedOutput schema / properties / effective_limit

Added value: +{
+  "description": "The response limit after clamping, present when clamped.",
+  "type": "number"
+}

addedOutput schema / properties / requested_limit

Added value: +{
+  "description": "The requested limit, present when clamped.",
+  "type": "number"
+}

First observedOct 2, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/openWorld, so the bar is lower, yet the description adds real behavior: an ambiguous multi-subregistry request returns a list rather than records, nested tables list rather than expand, and large registries page via cursor. These are non-obvious runtime traits that annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and there is no filler, but the single value-matching sentence is a deeply nested, hard-to-parse parenthetical that duplicates the schema's own exhaustive value semantics, inflating length without adding proportionate value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, complex filtering semantics, and an existing output schema, the description supplies the key non-schema behavior an agent needs (sub-registry fallback to a list, nesting behavior, pagination). Return-value formatting is rightly left to the output schema, so coverage is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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's detailed value-matching rules (digit vs 0x comparison, range rows) largely restate what the schema already documents, and it adds only marginal extras like the 'rec = Recommended column' convention.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read records from any IANA XML registry by id') with concrete examples (tls-parameters, protocol-numbers). It also distinguishes itself from the sibling iana_search_registries by naming it as the id-discovery path, so an agent can tell the two apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative for id discovery ('Find ids with iana_search_registries') and explains the alternative flow when multiple sub-registries exist (listing instead of records). It does not, however, contrast itself against the many iana_lookup_* siblings, so the when-to-use picture is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All iana-registries-mcp-server tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.