Neuronto ARD Registry: Agentic Resource Discovery (ARD) Index

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

Goes well beyond the annotations: it discloses the return shape (ranked matches with relevance score, endpoint, and carrying registries), warns that the score is not a trust or safety rating, explains the provenance of price terms (publisher manifest or the endpoint's own 402 answer) and that the caller pays the provider directly, and states the rate/price model. That is exactly the context readOnlyHint/openWorldHint/idempotentHint cannot convey.

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?

Front-loaded with the search action and scope, then return shape, then the score caveat, then payment mechanics — a sensible priority order with no filler. It is dense to the point of being a long paragraph, and the payment sentence packs several distinct facts that an agent must unpack.

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 no output schema, the description fully covers return values (ranked matches, score, endpoint, registries), the meaning of the score, and the cost model including the free tier — the things an agent needs before committing to a call. Federation behavior is only lightly covered ("at once" here, the faster-off note lives in the schema), but nothing blocking 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 coverage is 86%, so the schema already carries most parameter meaning; the description still adds value by explaining the payment filter categories and that price terms come from manifests or 402 answers, with direct provider payment. It does not touch limit, network, or federate, which are left entirely to 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?

States a specific verb and a well-enumerated resource set ("MCP server, skill, agent, API or other callable capability") plus scope ("across this index and every other public ARD registry at once"), which is concrete enough to act on. It never names its closest sibling find_tool, so an agent cannot tell from the description alone which of the two to pick.

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 is implied by "for a task" and by the filter guidance on payment ("free, payable, x402, mpp"), but there is no explicit when-to-use/when-not and no named alternative such as find_tool or registry_stats. The cost note ("2 free calls a day, then 0.1 USDC") does give the agent a practical budget consideration without saying what to do about it.

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 a safe read-only, idempotent, open-world profile, and the description adds genuinely new context: results are verified from a live server's tools/list, so names and input schemas are authoritative rather than claimed. It also discloses the billing model (2 free calls/day, then 0.1 USDC over x402 or prepaid credits), which annotations cannot express.

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?

Four short sentences, each carrying a distinct payload (provenance, differentiation, usage routing, cost), with the scope constraint front-loaded. Nothing is repeated from the title or 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?

No output schema exists, but the description conveys what is returned (tools with authoritative names and input schemas, optionally full JSON schema via with_schema). Missing only explicit mention of result ordering or the effect of the limit parameter.

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 67% and the two optional parameters (limit, with_schema) are already documented in the schema itself, so the description adds little. It only implicitly frames the query as a description of desired behaviour, leaving the description to do no more than the schema already does.

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 and resource ('Search individual MCP tools by name and behaviour') and immediately scopes it against the sibling concern ('not the servers that host them'). An agent can distinguish it from find_resource 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?

Gives explicit when-to-use ('when you know the shape of the call you need') paired with the named alternative and its condition ('use find_resource when you are looking for a service'). It also discloses the cost model, which affects invocation decisions.

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?

Goes well beyond the annotations by disclosing the verification gate (MCP initialize handshake for endpoints, parsable manifest for domains), the 30-day review window for free submissions, and the 5 USDC x402 cost plus immediate-listing effect of `priority`. The annotations only tell the agent this is a non-destructive, idempotent, open-world write; the description supplies the actual consequences.

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?

Four sentences, front-loaded with the action and the parameter choice, then verification, then pricing. The 'Nothing is taken on trust' sentence is slightly rhetorical but does communicate that failed verification blocks indexing, so it mostly earns its place.

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 no output schema, the description covers what gets checked, how long free review takes, and the paid fast path. It stops short of saying what the tool returns on submission (listing identifier, verification failure response), which is the only material gap for a create-style tool.

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%, so the baseline is 3, but the prose adds real meaning: the endpoint must survive an initialize handshake, the domain must resolve /.well-known/ard.json and parse, and priority swaps review latency for a 5 USDC charge. That is semantic value beyond the schema's example strings.

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 and resource: adds an MCP server endpoint or ARD domain to the index so other agents can discover it. The two accepted resource kinds are named explicitly, which cleanly separates it from the read-only siblings find_resource, find_tool, and registry_stats.

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?

Gives clear selection logic: use `endpoint` for an MCP server URL, `domain` for a site serving an ARD manifest, and `priority=true` when you want paid immediate listing instead of the 30-day review. It does not explicitly contrast against the sibling lookup tools, but the when-to-use context is unambiguous.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying what the statistics cover and the concept of introspection verification. No side-effect or return-format disclosure, but annotations cover the safety profile.

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?

A single sentence that packs four distinct aspects of the statistics without redundancy. It is front-loaded with 'How large this index is' and avoids 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?

For a parameterless read-only stats tool, the description covers what the operation tells you. There is no output schema, so a structured return format isn't specified, but the listed categories are sufficient for an agent to understand the tool's value. Minor gap: no explicit statement of the output representation.

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 tool takes zero parameters, so the schema is trivial. Per the baseline for parameterless tools, the description is not required to elaborate parameter semantics.

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 enumerates the exact content of the statistics (size, contents, verification, federated registries), which makes the tool's purpose identifiable. It lacks an explicit action verb like 'return' or 'show', but the title and description together clearly indicate a stats/inspection tool, and it is distinct from the find_* 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?

The description implies the tool is for retrieving index statistics, but does not state when to use it in preference to find_resource/find_tool, nor any exclusions. The purpose difference is obvious enough that an agent can infer usage, but explicit guidance is absent.

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