browse

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

With no annotations provided, the description carries the full transparency burden. It fully discloses the behavioral traits: the order of attempts (server card first, then MCP handshake), and for domains, the DNS lookup for _mcp TXT records. This goes beyond a generic 'inspect' and gives the agent a clear model of what happens when the tool is invoked.

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?

The description is concise and well-structured. It opens with the primary purpose, then succinctly explains the probing logic and domain-specific extra step. Every sentence earns its place, with no redundancy or filler.

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?

Given the tool's moderate complexity, no annotations, and no output schema, the description provides a thorough explanation of the tool's behavior but does not describe the return value or structure of the inspection result. This is a minor gap, as the agent may need to know what 'inspect' returns, but the core usage is well-covered.

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?

The schema already provides clear descriptions for both url and domain parameters. The description adds additional value by explicitly stating that for domains, DNS lookup for _mcp TXT records is performed, which is not mentioned in the schema. This clarifies behavioral differences between the two parameters and enriches parameter semantics beyond the schema.

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?

The description clearly states the tool's purpose: 'Inspect a domain or server URL.' It further distinguishes itself by detailing the exact probing behavior—well-known/mcp.json first, then MCP initialize handshake, plus DNS lookup for domains—making it specific and distinguishable from sibling tools.

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 when to use it: for inspecting a server or domain's MCP compatibility. It clearly explains the two modes (URL vs domain) and the fallback sequence, but it does not explicitly mention alternatives or exclusions relative to sibling tools like discover or discover_browse. Still, the usage context is clear and actionable.

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