Skip to main content
Glama

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

TableJSON Schema
NameRequiredDescriptionDefault
fieldNoColumn 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.
limitNoMaximum number of results to return, 1–100. Default 25.
valueNoExact 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".
cursorNonext_cursor from the previous page; reuse it only with the same registry, subregistry, value, field, and contains.
containsNoWords matched as whole tokens against every field and reference id, e.g. "chacha20". Records with a field equal to the words come first.
registryYesRegistry id, e.g. "tls-parameters", or its https://www.iana.org/assignments/<id> URL (a #fragment selects the sub-registry when subregistry is unset).
subregistryNoSub-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

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit applied.
errorNoPresent when the call failed. Absent on success.
notesNoNotes 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.
shownNoResults returned.
noticeNoGuidance on a miss, a cut list, or another condition.
offsetNoMatching records before this page, on pages after the first.
sourceNoProvenance and freshness of the answer.
columnsNoField (XML element) names seen, first-seen order, the first 50.
recordsNoRecords in registry order (with contains, records with a field equal to the words first), up to limit and a 48,000-character page budget.
truncatedNoTrue when more matches exist than were returned.
referencesNoThe documents that define the table read, the first 25.
totalCountNoMatches before the limit was applied.
descriptionNoDescription 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_cursorNoPass as cursor, with the same filters, for the next page.
registry_idNoRegistry id.
value_fieldNoThe table's key column: each record's value comes from it, and the value filter matches it unless field names another.
subregistriesNoTables 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_notesNoThe 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_titleNoRegistry title.
subregistry_idNoId of the sub-registry the records come from.
notes_truncatedNoTrue when notes or registry_notes were cut at 4,000 characters.
subregistry_titleNoTitle of that sub-registry.
registration_rangesNoAllocation ranges, when the table defines them: the first 25, each text at most 2,000 characters.
registration_procedureNoRegistration rule of the table read, or of the registry when listing; at most 2,000 characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, openWorldHint), but the description adds real behavior the annotations do not: sub-registry listing when none is specified, nested-table listing, field names being XML element names, and cursor-based paging for large registries.

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 core purpose is front-loaded, but the body is a single dense paragraph carrying long parenthetical matching rules that duplicate the schema. Much of the middle is redundant with structured fields and could be trimmed without loss.

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

Completeness5/5

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

An output schema exists, so return-value shape need not be explained. Given that, the description covers the remaining edge cases an agent needs: sub-registry listing, nested tables, pagination cursor reuse constraints, and the search sibling for id lookup.

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% and the value-matching prose in the description largely restates the schema's own text, including the digit/0x range semantics. The added value is mostly the worked examples, which do not go meaningfully beyond what the schema already documents, so the baseline 3 applies.

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?

Opens with a specific verb+resource ("Read records from any IANA XML registry by id") and grounds it with concrete examples (tls-parameters, protocol-numbers, http-methods, cbor-tags). It is clearly distinguishable from the narrow iana_lookup_* siblings and explicitly hands off id discovery to iana_search_registries.

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?

It routes the agent to iana_search_registries for finding ids and explains the fallback behavior when no subregistry is given. However, with nine siblings in the namespace, it never states when to prefer a specialized tool such as iana_lookup_port or iana_lookup_media_type over this generic reader.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.