StealthStack ARD Discovery

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and non-destructive, so the safety profile is covered. The description adds useful behavior content: it says the record includes the connect URL when provided, or inline connection/pull details otherwise, and that it returns type, publisher, version, trust, source, description, tags, and example queries. It does not mention auth requirements, rate limits, or error behavior for a missing URN.

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?

Two sentences, front-loaded with the primary action and resource, followed by return-content details. No filler. Could be slightly tighter given some returned fields are also implied by the output schema.

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?

For a single-record read tool with full annotation coverage, a 100%-covered one-parameter schema, and an output schema, this description is essentially complete: it specifies the lookup key, the source of that key, and the notable payload content. Missing only minor operational details like auth or not-found handling.

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 coverage is 100%, and the schema already documents the single identifier parameter with URN examples and accepted prefixes (urn:ai: and urn:air:). The description refers to the identifier/URN but adds no syntax or format detail beyond the schema, so baseline 3 is appropriate.

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 states a specific verb ('Get') and resource ('the full record for one discovered ARD resource by its identifier (URN)'), and explicitly names the sibling tools that produce the identifier ('as returned by search_resources / list_resources'). This lets an agent distinguish it from the list/search siblings 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is clear: it fetches a single record by URN, implying the identifier comes from list_resources or search_resources. It does not give explicit when-not-to-use guidance or state that search should be used for discovery, but the workflow is strongly implied by naming the siblings.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds useful behavioral detail (returns a count, kind breakdown, page of resources, connect URL or inline connection/pull details) and clarifies that paid is 'a filter, never a ranking' — a genuine non-obvious trait. But return content is largely restated and an output schema exists, so this is solid rather than exceptional.

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?

Two sentences, front-loaded with what the tool browses before the filter list, and the routing hint comes last where it belongs. No sentence is wasted.

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?

Annotations carry the safety profile and an output schema exists, so the description need not document return shapes exhaustively — yet it still sketches them. For a zero-required-parameter browse tool, nothing an agent needs 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.

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

Schema description coverage is 100%, so every parameter is already documented with its enum values and defaults; the baseline is 3. The description lists the same filters (kind, domain, trust, payment protocol) and adds only the parenthetical 'paid=x402', which is a marginal gain over the schema's own enum description.

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 (Browse) plus the resource (the StealthStack ARD index of agentic resources) and enumerates what lives there: agents, MCP servers, skills, catalogs. It is clearly distinguishable from get_resource (single item) and search_resources (targeted lookup) 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to the alternative: 'Use search_resources for a specific need,' implying this tool is for broad browsing. The conditional selection rule between browsing and searching is stated outright rather than inferred.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely useful behavior: results are ranked by the index's relevance score with best match first, and each result carries a connect URL or inline connection/pull details. It does not mention rate limits, auth, or pagination beyond the limit parameter.

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?

Three sentences, front-loaded with the core search action and scope, then ranking, then result shape. It is efficient overall, though '(best match first)' is mildly redundant with 'ranked by the index's relevance score'.

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?

With an output schema present, return-value detail is not required, and the description still sketches the useful part (connect URL vs. inline details). Six parameters are fully covered by the schema, required query is stated, and the search/filter/rank model is complete for correct invocation.

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%, so the schema already documents all six parameters with their enums and the limit default. The description's filter list and the 'paid=x402' note largely restate the schema rather than adding new meaning beyond it, so the baseline of 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?

The description names a specific verb and resource ('Search the StealthStack ARD index for agentic resources') and enumerates what is searched (agents, MCP servers, skills, catalogs). The free-text-over-name/description/tags mechanism and relevance ranking clearly separate it from the get_resource and list_resources siblings.

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?

It states the search context and which optional filters exist (kind, domain, trust, payment protocol), plus the clarifying note that paid=x402 'A filter, never a ranking.' However, it never names get_resource or list_resources or states when to prefer them over a query, so the routing guidance is context-only rather than explicit.

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