iana-registries-mcp-server

Look up an HTTP status code

iana_lookup_http_status

Read-onlyIdempotent

Look up an HTTP status code in the IANA registry, or search reason phrases. Pass exactly one of code (100–599) or keyword (e.g. "too many"). Returns the registered phrase, its class, defining reference with section, and whether it is temporary, obsoleted, or unused; an unassigned code returns found: false with the unassigned range it falls in.

Input Schema

Name	Required	Description
`code`	No	Status code to look up, 100–599 (a digit string such as "429" also works). Pass this or keyword, not both.
`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.
`offset`	No	Number of keyword matches to skip; pass the next_offset of the previous response to get the next page. Default 0.
`keyword`	No	Words matched as whole tokens against registered reason phrases, e.g. "too many" or "gateway". Pass this or code, not both.

Output Schema

Name	Required	Description
`cap`	No	The limit applied.
`mode`	No	Which lookup ran.
`error`	No	Present when the call failed. Absent on success.
`found`	No	True when a registered status matched.
`shown`	No	Results returned.
`notice`	No	Guidance on a miss, a cut list, or another condition.
`source`	No	Provenance and freshness of the answer.
`statuses`	No	Matching status codes: exact phrase hits first, then registry order.
`truncated`	No	True when more matches exist than were returned.
`totalCount`	No	Matches before the limit was applied.
`next_offset`	No	Pass as offset for the next page; absent on the last.
`effective_limit`	No	The response limit after clamping, present when clamped.
`requested_limit`	No	The requested limit, present when clamped.
`unassigned_range`	No	For an unassigned code, the registry range it falls in, e.g. "432-450".

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 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
```

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.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: the fields returned (phrase, class, reference with section, temporary/obsoleted/unused flags) and the not-found behavior ('found: false with the unassigned range it falls in'). Since an output schema exists, this return detail is partly redundant, capping it at 4.

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?

A single dense but well-front-loaded sentence: the primary action and mode selection come first, then the return shape. No filler sentences, though the packed return-value clause makes it heavier than strictly necessary given an output schema exists.

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 4-param, no-required-param lookup with a full output schema, the description covers everything an agent needs: the two mutually exclusive input modes, the valid code range, and the not-found semantics. Nothing material is missing.

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 schema already documents the code/keyword mutual exclusivity, ranges, and the limit clamping behavior. The description largely restates this ('Pass exactly one of code or keyword', the 100–599 range, the 'too many' example), adding little the schema does not already carry. 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?

States a specific verb (look up / search) and resource (HTTP status code in the IANA registry, reason phrases), with the dual mode (code vs keyword) made explicit. This clearly distinguishes it from siblings like iana_lookup_http_field, iana_lookup_port, and iana_get_registry_records.

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 a clear selection rule: 'Pass exactly one of `code` (100–599) or `keyword`'. This tells the agent when each input mode applies. However, it never names a sibling alternative or states when NOT to use this tool (e.g. vs. iana_search_registries), so it stops short of full routing guidance.

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.