iana-registries-mcp-server

Look up a port assignment

iana_lookup_port

Read-onlyIdempotent

Look up IANA service name and transport protocol port assignments. Pass exactly one of port (a number, 0–65535), service (an exact service name such as "postgresql"), or keyword (words matched against service names and descriptions). Results list every transport (tcp, udp, sctp, dccp) separately, report the registry range row containing an unassigned port, and classify the port as System (0–1023), User (1024–49151), or Dynamic/Private (49152–65535). Service names registered without a port (DNS-SD names) appear with no port.

Input Schema

TableJSON Schema

Name	Required	Description
`port`	No	Port number, 0–65535 (a digit string such as "443" also works). Returns every row for that port plus the range row containing it. Pass exactly one of port, service, or keyword.
`limit`	No	Maximum number of results to return, 1–100. 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 service names and descriptions, e.g. "network time". Pass exactly one of port, service, or keyword.
`service`	No	Exact service name, case-insensitive, up to 15 characters, e.g. "postgresql" or "whois++". Pass exactly one of port, service, or keyword.
`transport`	No	Keep only rows for this transport protocol. Rows without a transport (most range rows and every service name without a port) are always kept. Applies to every mode.

Output Schema

TableJSON 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 returned row has a registered service name.
`shown`	No	Results returned.
`notice`	No	Guidance on a miss, a cut list, or another condition.
`source`	No	Provenance and freshness of the answer.
`truncated`	No	True when more matches exist than were returned.
`port_class`	No	Port mode: the requested port's class.
`totalCount`	No	Matches before the limit was applied.
`assignments`	No	Matching rows. Port mode: exact rows, then range rows containing the port. Other modes: ascending by port, port-less rows last.
`next_offset`	No	Pass as offset for the next page; absent on the last.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description goes further by disclosing output behavior: per-transport rows, range rows for unassigned ports, System/User/Dynamic classification bands, and DNS-SD names appearing without a port. It adds real context, though some of it overlaps the output schema.

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

Conciseness5/5

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

Front-loaded with the core action, then the mode-selection rule, then result semantics and an edge case. Every sentence carries information an agent would otherwise have to infer; there is no filler.

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 values need not be re-explained, all six parameters are documented at 100% coverage, and the description supplies the one thing the schema cannot — how the three mutually exclusive modes behave and what the result set looks like. Nothing needed to call it correctly 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%, so the baseline is 3. The description restates the mutual-exclusivity rule and port bounds that each schema property already documents, adding little semantic meaning beyond the structured fields.

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 ('Look up IANA service name and transport protocol port assignments') and is instantly distinguishable from siblings covering other registries (HTTP status, media type, PEN, URI scheme, language tag). An agent can pick this tool without opening any 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?

Gives clear selection rules for the three lookup modes ('Pass exactly one of port, service, or keyword') and explains how keyword matches work. It does not, however, mention when to prefer this over the sibling iana_search_registries or state exclusions, so it stops short of a full 5.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.