agiscorecard-web3-permit

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

Annotations already declare readOnly, idempotent, and non-destructive; the description adds meaningful behavior: remote processing without persistence, incompatible shares staying unallocated, and disclaimed legal/enforcement functions. This goes beyond the annotation hints without contradicting them.

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 compact and front-loads the main function before the revenue split and boundary disclaimers. The list of disclaimed capabilities is a little long, but each sentence carries content and there is no 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?

With an output schema and detailed input schema, the description covers the main operational context: remote processing, no persistence, exact input retrieval via fetch, and non-legal boundaries. It is complete enough for an agent to invoke the tool correctly, though it leaves detailed validation to the schema.

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 schema already documents each parameter at a basic level. The description maps 'intended AI use' to the use parameter and 'received revenue' to receivedRevenue, but it does not add deeper semantics for asOf, region, currency, or datasets beyond what the schema provides.

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 leads with a concrete action: 'compares an intended AI use with your recorded grant conditions' and includes the revenue-split calculation. It distinguishes the tool's core from fetch by pointing to fetch for retrieving permits, though it does not explicitly compare it against the other 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 intended use is implied: use when you need to match an AI use against grant conditions and split revenue. It tells users to retrieve exact inputs via fetch or the example resource, and lists disclaimed functions (no legal opinion, enforcement, etc.), but it does not explicitly state when to use this tool over 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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: the payload is methodology/limits/source links/worked examples, it contains 'no user records', and the caller is instructed to cite the canonical URL. It does not discuss failures or rate limits, but for a read-only lookup that is minor.

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 compact sentences, front-loaded with the retrieval action and immediately followed by payload scope. No filler, though the final imperative ('Cite the returned canonical URL') sits slightly awkwardly inside a retrieval description.

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?

Rich annotations plus an output schema mean the definition does not need to describe return shape; it still adds source-of-truth guidance (ID from search) and the citation obligation. For a one-parameter, read-only tool this is close to sufficient, with only the opaque enum value left unaddressed.

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 0% and the sole enum value ('permit') is unexplained, so the description must carry the load. It does add meaning by stating the id comes from search results, but it never explains what a valid id looks like or that the enum currently admits only one value.

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+resource ('Retrieve a public tool reference') and distinguishes it from the search sibling by specifying the input is 'the ID returned from search'. A reader can tell this is the follow-up lookup step rather than the discovery step, though the title's 'Web3 method' framing is never echoed in the body.

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 phrase 'by the ID returned from search' implies the prerequisite call sequence, which is real usage guidance. However, there is no explicit when-not, no mention of check_data_permissions, and no statement of what happens if the ID is invalid or absent.

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 establish read-only, idempotent, non-destructive behavior, and the description adds valuable behavioral context: bilingual (English and Chinese) name support, public scope, and the empty-query listing behavior. These details go beyond what annotations or schema provide without contradicting them.

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 two clean sentences with no filler. The primary action is front-loaded, and the supporting usage details are kept minimal and relevant.

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-parameter search tool with annotations and an output schema, the description is complete: it defines the search scope, supported query forms, and the empty-query behavior. No essential information for invoking the tool 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 coverage is 0%, so the description carries the burden of explaining the query parameter. It clarifies that queries are names, that English and Chinese are accepted, and that an empty query has special meaning. It does not fully specify matching behavior (e.g., exact vs partial), but it compensates well for the schema gap.

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 ('Search') and resource ('this server’s public AI/Web3 tools and citation pages'), making the tool’s function immediately clear. It is distinct from all sibling tools, which focus on checking permissions, comparing costs, or reading profiles rather than searching a corpus. The title and description align well.

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 clearly indicates when to use the tool: when searching for AI/Web3 tools or citation pages on this server. The note about empty query listing available worksheets provides a concrete usage scenario. It does not explicitly name alternatives or exclusion conditions, so it misses the top score.

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