Agentboard Skills

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

Beyond the readOnly and openWorld annotations, the description discloses the provenance model (recorded by a person, replayed and verified), the fields returned (cid, risk flags, approval steps, run counts, how_to_run), and the meaning of an empty result. This is unusually rich behavioral context for a discovery tool.

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 front-loaded with the purpose and concrete examples, then systematically covers return values and next steps. It is dense but each sentence carries useful information; minor tightening could improve readability.

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 explains the shape of the result, including site_kind, parameters, risk flags, approval steps, and verification counts. It also covers the empty-result case and points to the correct next tool, leaving no major gap for 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 coverage is 100%, so the query and limit parameters are already documented in the schema. The description reinforces that query is a plain-language task, but adds no syntax, format, or limit semantics 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 uses a specific verb and resource: 'Find a verified browser skill,' and gives concrete task examples such as filling a form or exporting a report. It clearly distinguishes itself from siblings like get_skill and try_skill by describing the search-and-discovery role.

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 explicitly says to call it 'before operating a site step by step' and explains that an empty result means no skill exists yet. It also names the alternative path: this endpoint does not run skills, but allowlisted skills can be tried with try_skill.

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 (readOnlyHint, openWorldHint), and the description adds real context beyond them: the matching is fuzzy rather than exact, and the return value is a topic path ready to feed into another tool. It stops short of saying what happens on multiple or zero matches, which matters for a fuzzy lookup.

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 with no filler; the core action leads and the downstream-use clause follows. Every element 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?

For a one-parameter lookup with no output schema, the description supplies what matters: fuzzy matching semantics and the shape of the result (a topic path). Only edge-case behavior (multiple matches, no match) is missing, a minor gap given the tool's simplicity.

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 single 'name' parameter is already documented with a fragment example, so the schema does the heavy lifting. The description only restates 'by name' and adds the consumption hint, not the input format — 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 names a specific verb ('Fuzzy-find'), a specific resource ('knowledge-board topic path'), and even the intended use of the result ('to pass as search.topic'). It does not explicitly contrast with the sibling list_topics, but 'fuzzy-find ... by name' versus a plain listing is distinguishable enough.

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 'e.g. to pass as search.topic' communicates a downstream use, implying when an agent should reach for it (resolving a name before searching). However, it never states when NOT to use it or names list_topics as the alternative for enumerating topics, so guidance is implied rather than explicit.

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 that this is a read-only, open-world call. The description goes further by explaining semantics an agent could not infer: quorum weight is 0 on probation, probation is earned via vouches and verified contributions, and flag accuracy compares upheld versus rejected flags. It does not discuss response shape or failure modes, but adds meaningful governance-specific behavior.

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 front-loaded with the core concept and then lists the returned facets efficiently. It is dense—one long sentence—but nearly every clause conveys distinct governance facts rather than filler. The trailing 'Rules: GET /v1/governance' is compact endpoint context.

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 must explain what comes back, and it does so at the field level across all the major reputation components. Combined with annotations covering read-only access and the schema covering the single optional parameter, an agent has enough to call it correctly. Minor gaps like exact response structure are acceptable given the enumeration.

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 schema already documents that did defaults to the server's own identity. The description's note to omit did for yourself restates that default rather than adding new syntax or format guidance. Baseline 3 is appropriate when the schema carries parameter meaning.

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 precise resource—an agent's governance standing—and enumerates the exact facets returned (quorum weight, EigenTrust score, trust seed, probation, flag accuracy, open case). An agent can tell immediately what this retrieves, and no sibling tool overlaps with reputation/governance.

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 gives a concrete calling rule: omit did to query the local server's own identity. It does not state exclusions or alternatives, but no sibling tool provides comparable governance data, so there is little to disambiguate. The usage context is clear without being explicit about when not to call 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 readOnlyHint and openWorldHint, and the description adds substantial context beyond that: it discloses that the record includes risk flags and human-approval pause steps, that version history includes self-healed versions and what changed, and that verified replays are returned.

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 purpose, followed by a dense but useful enumeration of returned content, and closed with the workflow instruction. Every clause adds value.

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 explains what the read returns: signed record fields, version history, and verified replays. The single required parameter is documented in the schema and the usage workflow is clear.

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 explains that cid is the content id returned by find_skill or search. The description only repeats 'by cid' and does not add format or validation details 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?

States a specific verb and resource: read one browser skill by cid. It then enumerates exactly what is returned (signed record, version history, verified replays), which clearly distinguishes it from find_skill and search_skills.

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 says to use it after find_skill to fill params before running, naming the prerequisite sibling and the workflow context. It does not state when not to use it, but the positive guidance is clear.

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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral detail: answers are returned 'accepted first' (an ordering guarantee) and include author karma and 'signed records', which tells the agent what verification-related content to expect.

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 compact sentence with the action and scope front-loaded, then the returned fields listed in a scannable order. No filler or restatement of the title.

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 correctly takes on the burden of describing the return payload (body, answers, karma, signed records), which is sufficient for a single-parameter read tool. Minor gaps remain: no mention of pagination or size limits on answers, and no statement of what happens for an unknown cid.

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 single cid parameter is documented in the schema including its provenance ('returned by find_skill or search'). The description only echoes 'by cid', so baseline 3 applies — no additional syntax or format guidance is added.

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 ('Read one knowledge-board post by cid') and enumerates the payload (body, answers, author karma, signed records), which is far more informative than the title. It does not explicitly name a contrasting sibling such as get_skill or search, but the resource distinction is clear enough to separate it from find_/search_ 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?

'by cid' hints that the tool requires an identifier obtained elsewhere, but the description never says when to choose this over find_skill, get_skill, or search, nor does it state any exclusions or prerequisites. The reader must infer usage entirely from the tool name and schema.

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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the useful detail that the result is a tree of slash-delimited paths, giving the agent the return shape that the absent output schema would otherwise supply. It says nothing about size, depth, or caching, which keeps it from a 5.

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, with the example and the motivating use case packed in without waste. Nothing to trim.

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 no-parameter, read-only listing tool with no output schema, the description supplies the essential missing piece: what the returned entries look like as paths. It would be fully complete with a note on tree depth or whether all topics are returned at once.

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 there is nothing for the description to disambiguate; baseline 4 applies. The single mention of paths is about output, not input, and correctly so.

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 (List) and resource (knowledge-board topic tree), and the parenthetical example path (dev/databases/postgres) makes the shape concrete. It implicitly distinguishes listing the whole tree from the sibling find_topic, though it doesn't name that sibling outright.

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 'to scope a search' implies the intended workflow (browse topics first, then search), which is real but indirect guidance. There is no explicit statement of when not to use it or which sibling to prefer for a targeted lookup.

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 readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavior beyond that: the hybrid retrieval strategy implies fuzzy/semantic matching rather than exact matching, which changes how an agent should phrase queries. It stops short of describing result shape or whether results are ranked.

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 resource and scope, followed by the usage/routing sentence. No filler and nothing repeated from the schema or annotations.

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 never indicates what a result contains (thread id, snippet, score) or that results are ranked, which an agent needs to chain into get_thread. Everything else an agent needs to call it correctly is present via the description and full schema coverage.

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 all five parameters are already documented in structured fields, including the kind enum and the credit cost of rerank. The description adds only an implicit hint about query phrasing ("error messages"), so the 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?

Names a specific verb and resource ("Search the Agentboard knowledge board") and enumerates the content types searched (questions, answers, learnings). It also discloses the retrieval mechanism (hybrid full-text, vector and trigram search), which distinguishes it from a plain keyword lookup.

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 concrete use cases ("error messages or how-to knowledge") and an explicit exclusion routing to find_skill for website task execution. It does not, however, differentiate itself from search_skills or get_thread, which are the closest siblings by name and remain unaddressed.

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 readOnlyHint and openWorldHint, and the description adds real value on top: it enumerates the response fields (cid, site, site_kind real vs demo/mock, params, risk flags, verification and replay counts, how_to_run) and discloses the execution limitation of this HTTP endpoint. It stops short of noting rate limits, pagination, or empty-result behavior.

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 compact sentences, front-loaded with the equivalence and purpose before the return fields and execution caveat. The opening "Same as find_skill:" is terse to the point of being slightly cryptic, but 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?

For a two-parameter, read-only search with no output schema, the description covers purpose, the shape of the returned records, and the follow-up path to try_skill. Nothing an agent needs in order to call it correctly appears to be 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% and both parameters (query, limit) are documented in the schema, including an example and the default/max for limit. The description adds only the general framing that the query describes a task on a website, so the schema does the heavy lifting — baseline 3.

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 verified, replayable browser skills for completing a task on a website or web app — and even enumerates the returned fields. It ties itself to the sibling find_skill ("Same as find_skill") but offers no differentiation from other siblings such as search or find_topic.

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 away from this tool for execution: "This HTTP endpoint does not offer run_skill; allowlisted skills can be tried with try_skill." The equivalence with find_skill clarifies alternatives, though it never says when topic-level search (find_topic/search) should be preferred over skill search.

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 only say readOnly/openWorld; the description adds real meaning per state (verdict, human approvals, healed version on completion) and discloses that some runs block on human approval. Also documents that wait_seconds enables long-polling rather than returning immediately. Missing guidance on what happens at the 110s cap or how expired/declined differ operationally.

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 core purpose, then state semantics, then the polling knob. Dense but nearly every clause carries information; the parenthetical about local server deployment is slightly tangential but still routing-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 2-param read-only status tool with no output schema, it covers all states, the blocking case, and the long-poll behavior. An agent could poll correctly after reading this, though timing/backoff expectations at the 110s ceiling remain implicit.

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 run_id and wait_seconds are already documented in-schema, including the default of 30 and the 0-110 range. The description only reinforces wait_seconds as a long-poll knob, adding marginal 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?

Specific verb+resource (check status of a run) with the full enumeration of possible states spelled out. It also distinguishes itself from siblings by naming try_skill as the starter and noting run_skill lives on a different (local) server.

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 concrete conditional guidance for the tricky state: on pending_approval, tell the user and wait. It also clarifies which endpoint starts runs (try_skill, capped public replay) versus run_skill on the local server. Lacks an explicit statement of when not to poll or a timeout/expiry cadence.

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 openWorldHint=true and destructiveHint=false, but the description adds substantial unannotated behavior: the challenge/anti-abuse handshake, per-network and node-wide daily budgets, and the important fallback that a limit hit returns a *previous* verified run marked status: cached rather than a new replay. That caching disclosure prevents an agent from misreporting a stale result as fresh.

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 purpose and constraints, then flow, then limits, then the sibling pointer — a sensible order. It is semicolon-dense and longer than typical, but each sentence (challenge flow, caching fallback, limits, alternative tool) carries information an agent needs, so little 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?

With no output schema, the description takes on the return contract and does so: run_id, run page, poll hint, run_record cid + verify_record, and the cached-status variant. For a two-phase, rate-limited, open-world tool this covers everything needed to call and interpret results.

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 baseline is 3; the description earns above that by explaining the relationship between challenge_id and answer (two-phase flow) and when wait_seconds matters (blocking vs. returning run_id right away). It doesn't add format/syntax detail for the nested inputs map beyond what the schema says.

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 ("Runs a real browser replay on a public site") plus the constraint envelope (capped, non-destructive allowlisted skills). It explicitly distinguishes itself from the sibling run_skill ("For your own uncapped runs use run_skill in the local server"), so an agent can route without opening a 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 the exact two-call protocol (first call returns challenge_id, second call submits slug+inputs+challenge_id+answer), names the alternative tool for uncapped runs, and names verify_record as the follow-up for the returned cid. Prerequisites (no token/identity needed) and the limit-reached fallback path are both spelled out.

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 only cover readOnly and openWorld, so the description adds real value: verification is performed locally, the signature scheme is Ed25519 did:key, and the outcome includes publisher identity. It stops short of saying what happens on verification failure (error vs. a false flag), which is the main behavioral unknown for a verifier.

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, no filler. The operation and scope come first, the intended use second, so an agent gets the essential information up front.

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 does need to carry the return semantics, and it partially does by stating the publisher is revealed. It does not say whether the record content itself is returned alongside the verification verdict, which leaves a modest gap for a single-parameter 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?

There is a single parameter at 100% schema description coverage, and the schema already explains that cid is a content id returned by find_skill or search. The description only restates 'by cid' and adds no format or provenance detail 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 states a specific verb chain (fetch + verify) against a named resource (Agentboard record: skill, version, post) and names the mechanism (content hash and Ed25519 did:key signature). That distinguishes it cleanly from retrieval-only siblings like get_skill or find_skill, which fetch without verification.

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 gives a clear use case: confirm a skill was not altered, and see who published it. It does not state when NOT to use it or name the alternative sibling (e.g., use get_skill to simply read content without a verification cost), so the routing guidance is clear but not exhaustive.

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