iana-registries-mcp-server

Get RFC, Internet-Draft, and series status

iana_get_rfc_status

Read-onlyIdempotent

Get the current status of up to ten distinct RFCs, Internet-Drafts, or BCP/STD/FYI series per page from up to 1,000 input items. Canonical aliases resolve once. When more remain, deferred_ids previews the next ten, deferred_count counts the whole remainder, and next_ids_offset continues the same original ids. Retry failed ids separately. Accepts "RFC 9110", "rfc9110", "9110", draft names with or without a revision suffix ("draft-ietf-httpbis-semantics-19"), series numbers ("BCP 14"), RFC and draft file names ("rfc9110.txt"), the URL of an RFC or draft on datatracker.ietf.org, tools.ietf.org, or ietf.org or of an RFC on rfc-editor.org, and a series URL at rfc-editor.org/info/ or datatracker.ietf.org/doc/ ("https://datatracker.ietf.org/doc/bcp14/"). RFCs return current and as-published status, stream, working group, obsoletes/obsoleted-by and updates/updated-by relations, the series they belong to, and the errata page; drafts return their state, IESG state, intended status, expiry, the document that replaced them, and the RFC they became; a series returns its member RFCs. Unknown ids return found: false. A call makes at most 20 Datatracker requests, retries included (an RFC or a series needs one, plus one per call for the RFCs' series; a draft three, or four with a revision suffix): each id is taken in request order if its requests still fit, and the others come back in failed with reason request_limit, to pass in another call.

Input Schema

Name	Required	Description	Default
`ids`	Yes	Up to 1,000 normalized nonblank RFC, Internet-Draft, or series items; aliases are canonically deduplicated before selecting ten distinct ids. One comma-, semicolon-, or newline-separated string is also accepted. Resubmit the same ids with next_ids_offset as ids_offset to continue.
`ids_offset`	No	Number of canonically distinct ids to skip, default 0. Pass next_ids_offset with the same original ids to continue; retry failed ids separately.

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`failed`	No	Ids whose lookup failed upstream or was cut by the call's request limit; the rest of the batch still answered.
`notice`	No	Set when ids were left unresolved at the call's Datatracker request limit, or when Datatracker fields (stream and group, or series membership) were unavailable for some RFCs.
`documents`	No	One entry per distinct requested id, in request order, excluding ids in failed.
`total_ids`	No	Total canonically distinct ids before ids_offset and the ten-id batch limit.
`deferred_ids`	No	Preview of the next at most ten canonical ids, not the entire remainder; no upstream work started for these ids.
`deferred_count`	No	All distinct ids remaining after this selected batch, including ids beyond the preview.
`deferred_reason`	No	More distinct ids remain beyond the ten-id batch limit.
`next_ids_offset`	No	Pass as ids_offset with the same original ids to resolve the next batch; absent at or past the end.
`deferred_guidance`	No	How to continue the original id list and retry selected failed ids separately.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 17, 2026

changedInput schema / properties / ids / description

Previous value: -"Up to 10 RFCs, Internet-Drafts, or series, e.g. [\"RFC 9110\", \"BCP 14\", \"draft-ietf-httpbis-semantics-19\"]. One comma-, semicolon-, or newline-separated string is also accepted."New value: +"Up to 1,000 normalized nonblank RFC, Internet-Draft, or series items; aliases are canonically deduplicated before selecting ten distinct ids. One comma-, semicolon-, or newline-separated string is also accepted. Resubmit the same ids with next_ids_offset as ids_offset to continue."

changedInput schema / properties / ids / maxItems
```
Previous value: -10New value: +1000
```

addedInput schema / properties / ids_offset

Added value: +{
+  "default": 0,
+  "description": "Number of canonically distinct ids to skip, default 0. Pass next_ids_offset with the same original ids to continue; retry failed ids separately.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

changedOutput schema / anyOf

Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "documents",
-      "failed"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "total_ids",
+      "deferred_ids",
+      "deferred_count",
+      "documents",
+      "failed"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / deferred_count

Added value: +{
+  "description": "All distinct ids remaining after this selected batch, including ids beyond the preview.",
+  "type": "number"
+}

addedOutput schema / properties / deferred_guidance

Added value: +{
+  "description": "How to continue the original id list and retry selected failed ids separately.",
+  "type": "string"
+}

addedOutput schema / properties / deferred_ids

Added value: +{
+  "description": "Preview of the next at most ten canonical ids, not the entire remainder; no upstream work started for these ids.",
+  "items": {
+    "description": "One canonical id.",
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / deferred_reason

Added value: +{
+  "const": "batch_limit",
+  "description": "More distinct ids remain beyond the ten-id batch limit.",
+  "type": "string"
+}

addedOutput schema / properties / next_ids_offset

Added value: +{
+  "description": "Pass as ids_offset with the same original ids to resolve the next batch; absent at or past the end.",
+  "type": "number"
+}

addedOutput schema / properties / total_ids

Added value: +{
+  "description": "Total canonically distinct ids before ids_offset and the ten-id batch limit.",
+  "type": "number"
+}

First observedOct 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Drops the annotation bar and goes well past it: a hard budget of 20 Datatracker requests per call, per-id request costs (1 for an RFC/series plus one for its series, 3-4 for a draft), the request-order allocation rule, and the request_limit failure reason for the remainder. It also discloses unknown ids return found: false and that canonical aliases resolve once, which an agent needs to predict behavior.

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

Conciseness4/5

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

Front-loads the core operation and the pagination trio before the long input-format inventory, and every sentence carries information. It is dense and the accepted-format examples partly duplicate the schema's items description, keeping it short of a 5.

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?

For a two-parameter tool with pagination, request budgeting, and alias resolution, the description covers continuation, failure semantics, and return shape (RFC vs draft vs series fields). With an output schema present it did not need to explain returns, yet the extra detail is accurate and useful.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real semantics: canonical alias deduplication before selecting ten distinct ids, the exact continuation contract between next_ids_offset and ids_offset, and the one-string comma/semicolon/newline form. The accepted-id-format list is largely mirrored in the schema, so it does not push higher.

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: get the current status of RFCs, Internet-Drafts, or BCP/STD/FYI series. The scope is far from the sibling lookup tools (registries, media types, ports, HTTP fields), so no ambiguity arises about which tool handles document status.

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?

Gives clear operational guidance: how to paginate with deferred_ids/deferred_count/next_ids_offset, and to retry failed ids separately with the same original ids. It does not explicitly name alternatives or exclusions, but no sibling overlaps this resource, so the missing step is minor.

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.