Use This Skill

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: content is gated, and Pro-gated proofs need a Pro license key for full pages. It does not state that this is a read-only lookup, what happens on a missing/unauthorized proof, or whether the response is truncated for non-Pro callers.

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 dense sentences with no filler; the contents of the proof are front-loaded before the access caveat. Slight deduction because the opening sentence is a noun phrase rather than a direct statement of the operation.

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?

Because there is no output schema, the description usefully enumerates the returned fields, which partially compensates. But with one undocumented required parameter, no annotations, and no usage routing, an agent still lacks what it needs to invoke this confidently versus its siblings.

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 single parameter 'slug' has 0% schema description coverage and is never mentioned in the description. 'The proof for a skill' weakly implies the slug identifies a skill, but there is no format hint, no indication of where to obtain it, and no relationship to the identifiers used by sibling tools.

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 the resource (the proof for a skill) and enumerates what it contains—fixed brief, model, skill commit, result-page links—so the artifact is clear. However, it never states the action explicitly (retrieve/fetch) and does nothing to separate it from get_skill, order_proof, or list_proven, leaving an agent to infer the distinction from names alone.

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?

There is no when-to-use guidance and no named alternative, despite get_skill and order_proof being obvious confusables. The only conditional is a licensing prerequisite ('Full pages for Pro-gated proofs require a Pro license key'), which is a constraint rather than selection guidance.

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?

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: the SKILL.md text is returned conditionally, 'when the license allows it'. That license-gated variability is genuinely useful. However it says nothing about unknown-slug behavior, error modes, or authentication, so the disclosure is partial.

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, no filler, and the key scoping constraint ('one skill by slug') plus the returned fields are front-loaded. Every clause carries information.

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?

There is no output schema, so the description rightly enumerates the returned fields (install command, source link, license, SKILL.md). For a simple single-parameter read tool this is nearly complete; only error and license-fallback specifics are absent.

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%, so the description must compensate; 'by slug' is the only semantic it supplies, establishing the identifier type but not format, case sensitivity, or where a slug comes from. This is the minimum needed to call the tool, not more.

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 concrete verb (get) and resource (one skill), and the phrase 'one skill by slug' implicitly separates it from the sibling search_skills, which returns many. It also enumerates what the record contains, so the agent knows what it gets back. It stops short of explicitly naming the alternative, so not a 5.

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 only implied: 'by slug' signals this is the follow-up to a search that produced a slug, but there is no explicit when-to-use or when-not-to-use statement and search_skills is never named as the alternative. Adequate but leaves the routing to inference.

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?

No annotations are provided, so the description bears the full behavioral burden, yet it only explains what a 'proof' is conceptually. It says nothing about return shape, ordering, pagination, or count limits for what is evidently a list endpoint.

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 compact sentence with no filler, and the defining qualifier ('have a published proof') is placed first. It is efficient, though it lacks an explicit action verb to front-load.

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 zero-parameter list tool with no output schema and no annotations, the description covers the domain concept but omits whether a list is returned, how items are ordered, and whether results are paginated. Adequate but with clear gaps against the tool's actual shape.

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. No parameter-level gaps exist to compensate for.

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 defines the domain concept ('skills that have a published proof') but never states the operative verb — it reads as a definition rather than 'returns/lists skills'. An agent can infer it is a listing operation from the name, but the sentence itself doesn't assert what the tool does, and it doesn't distinguish itself from search_skills or get_skill.

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?

There is no when-to-use guidance and no mention of the siblings (search_skills could plausibly surface the same set). Nothing tells the agent when to choose this over get_proof or get_skill, so selection must be inferred entirely from the name.

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?

With no annotations, the description carries the full behavioral burden and does disclose two useful traits: the $49 cost and that processing is automatic, plus what it returns (the order link). It omits whether this is a paid mutation, what auth or account is required, and what happens after the order is placed.

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 short, front-loaded sentences with no filler; the core action and the return value are both stated in under twenty words.

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 tool with no output schema, the description covers the return value ('the order link') and the cost, which is adequate. It falls short on the input parameter and on the account/auth context an agent would need before invoking an ordering action.

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% and the single parameter skill_github_url has no description in the schema. The description only alludes to 'their own skill' and never explains that a GitHub URL must be supplied or in what form, so it does not compensate for the coverage 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+resource (order a proof) and scopes it to a skill author proving their own skill, which is enough to distinguish it from read-only siblings like get_proof and list_proven. It is framed as a 'how you get proven' explanation rather than a direct action statement, but the intent is unmistakable.

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 'a skill author gets their own skill proven', so the audience and situation are inferable. However, it never states when to use this over get_proof or search_skills, nor any prerequisite such as having the skill already published on GitHub.

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?

With no annotations, the description carries the full behavioral burden; it usefully discloses the result payload (name, description, category, source repo, install command, proof existence), which is real return-format information. However it says nothing about ranking/relevance ordering, the limit cap, or read-only safety, so it is only partially transparent.

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 short sentences, zero waste, purpose front-loaded before the return summary. Every clause 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 correctly explains the return fields and the tool is simple (3 params, 1 required). But the absence of any usage guidance or selection criteria against four sibling tools leaves the definition only minimally complete.

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 description contributes essentially nothing about the three parameters, adding no syntax or filtering semantics beyond the schema. 'For a task' loosely frames the query parameter but adds no real meaning, 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?

States a specific verb and resource ('Find agent skills') plus the scoping condition ('for a task'), and enumerates what it returns, which helps separate it from the single-item sibling get_skill. It never names a sibling or explicitly contrasts with get_skill/list_proven, so it falls short of a 5.

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?

There is no when-to-use guidance, no exclusions, and no mention of the alternatives (get_skill, get_proof, list_proven). 'For a task' merely restates the purpose rather than telling the agent which tool to pick in which situation.

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