Look up any TCP/UDP port number (1-65535) to identify its IANA service assignment and typical application purpose, helping explain network ports and service exposure.
Inspect network port number (1-65535) for standard IANA service assignment, transport protocol (TCP/UDP), and typical application purpose.
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes | TCP/UDP port number between 1 and 65535 (e.g. 3000, 5432, 6379) |
Changes observed during successful MCP inspections.
v1.3.4Input schema / additionalPropertiesAdded value: +falseInput schema / properties / port / descriptionPrevious value: -"Port number between 1 and 65535"New value: +"TCP/UDP port number between 1 and 65535 (e.g. 3000, 5432, 6379)"v1.3.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the agent knows this is a safe, repeatable lookup. The description adds the range constraint (1-65535) and the shape of the answer, but no extra behavioral context such as lookup source, offline vs online resolution, or completeness guarantees. With annotations carrying the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, no filler or redundancy. It earns its length entirely by enumerating what the inspection returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description usefully pre-declares the three fields the caller will get back (IANA assignment, transport protocol, application purpose), which is the main missing structured information. Adequate for a simple one-parameter lookup, though it could mention result reliability or unknown-port behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented there with the 1-65535 range and examples (3000, 5432, 6379). The description merely restates the same range, so it adds no meaning beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Inspect") and resource ("network port number") plus the exact information returned (IANA service assignment, TCP/UDP protocol, typical application purpose). The domain is clearly distinct from siblings like castov_jwt_decode or castov_cidr, though it never names a sibling to route against, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (you have a port number and want to know what service it maps to), but it never states when to use this versus alternatives or any preconditions. No exclusions or sibling routing are given, so it is implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.