skills

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

Annotations already declare readOnlyHint=true, and the description adds substantive detail about what the response contains (install prompt, setup steps, safety notes) plus a comparative note that this tool omits raw SKILL.md and setup questions. It does not mention any rate limits or auth needs, but for a read-only getter 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 sentences, zero filler. The contents listing comes first and the alternative-tool routing second, which is the right order for an agent deciding whether to call it.

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, so the description must describe return content, and it does so concretely. What it omits is output shape or size (e.g., whether the prompt is a string or structured object), which would help an agent plan downstream formatting.

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 both parameters are already documented, including the slug example and the platform enum. The description only echoes that the prompt is tailored to 'the chosen assistant,' adding nothing 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?

States a specific verb and resource ('Get one skill's install kit') and enumerates the returned artifacts (install prompt with SKILL.md, setup steps, data-access and safety notes). It also names the closely related sibling install_skill, so an agent can distinguish the two without opening either 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: 'Prefer install_skill, which also returns the raw SKILL.md and setup questions.' That gives a clear alternative and the reason to choose it. It stops short of stating an affirmative 'use this when you only need the install prompt' condition, so it is strong but not fully bidirectional.

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?

The description details highly destructive or state-changing processes ('saves every member skill,' 'creates each routine'). This heavily implies write operations, which directly contradicts the `readOnlyHint: true` annotation, creating a significant behavioral ambiguity for the agent.

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 definition is highly dense and efficient, using a single, comprehensive sentence to cover the functionality, output components, and input requirements effectively.

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?

Since there is no output schema, the description is highly complete by explicitly listing all components that constitute the 'install kit,' including safety notes, merged members, and URLs.

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?

Although schema coverage is 100%, the description adds vital context to the 'platform' parameter by explaining that it is used to 'tailor the install' for specific environments like grokBot or gemini, making the enum functional context useful.

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 tool clearly defines its purpose as gathering a 'combined install kit' for an entire bundle. It provides highly specific details about the kit's contents, which clearly differentiates it from single-skill tools in the sibling list.

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?

While the term 'bundle' implies its intended use, the definition does not explicitly guide the agent on whether to use this for initial setup versus when a specific skill install (e.g., install_skill) is appropriate. The usage is implied rather than explicitly guided against alternatives.

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?

readOnlyHint=true is already declared, and the description adds meaningful context the annotation cannot: this tool produces content for the caller to act on rather than performing the installation itself, and it spells out which downstream actions are unconditional (save skillMd, ask questions once) versus conditional (create the routine only if the user agrees). It does not discuss failure modes for an unknown slug, but the behavioral profile is materially clearer than the annotation alone.

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 with no filler; the payload enumeration is front-loaded and the action instructions follow. The long comma-separated list of deliverables reads as dense but every item conveys scope the agent otherwise wouldn't know.

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, and the description essentially serves as one by enumerating exactly what comes back and what the agent is expected to do with each piece. For a two-parameter read-only tool, nothing essential for correct invocation 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 100% and both parameters carry descriptions, including the platform enum and its default, so the schema does the heavy lifting. The description only gestures at parameters indirectly through "the ready-to-paste prompt for your platform," adding no format or constraint 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?

Names a specific verb and resource ("install one skill") and immediately enumerates the payload (SKILL.md text, prompt, steps, schedule, questions, safety notes, URLs), so an agent knows this is a one-shot install package rather than a lookup like get_skill. The "one skill" scope implicitly distinguishes it from install_bundle and install_team, but none of those siblings are named explicitly.

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 workflow guidance for what to do after calling ("Save skillMd as a skill, ask the setup questions once, and create the routine only if the user agrees"), which is genuinely useful sequencing. However, it never states when to choose this over get_skill or install_bundle/install_team, so the routing decision is left 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?

Annotations only give readOnlyHint=true; the description adds the key behavioral fact that this returns a prompt/install kit rather than performing an install. It also discloses the output shape differs by platform (one bot per role + shared group chat on grokBot vs. a single assistant elsewhere) and that safety rules are embedded. Missing: whether output is cached/versioned or how it behaves for an unknown id.

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 dense sentence with the object of the call front-loaded ('Get one team's install kit') and the platform branching subordinated after. Every clause carries information, though the nested parenthetical makes it a slightly heavy read.

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, so the description must carry return-value meaning — and it does, describing the prompt's contents and its platform-dependent form. Adequate for a 2-parameter read tool; only error/not-found behavior is 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 coverage is 100%, so baseline is 3, but the description earns an extra point by explaining that 'platform' materially changes the generated kit structure (multi-bot vs. single assistant), which is meaning beyond the enum list.

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: "Get one team's install kit" followed by what the kit actually is (a prompt). The name 'install_team' is clarified as a non-executing fetch, which prevents misreading. It doesn't explicitly contrast itself with install_skill/install_bundle, so sibling differentiation is left implicit.

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: the id parameter says 'wins from list_teams', suggesting the precede-tool, and the platform enum hints at tailoring. But there is no statement of when to prefer this over install_skill, install_bundle, or get_skill, and no exclusions.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds domain context (bundles are curated sets that install together) but says nothing about pagination, result volume, or what fields a listed bundle carries. Useful but thin beyond the annotation.

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 clarifying example placed immediately after the term it defines. Nothing is wasted or buried.

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 read-only list tool, the definition covers what the resource is and how it relates to installation, which is the main ambiguity an agent faces here. The only gap is that with no output schema, nothing indicates what a listed bundle entry contains (name, id, included skills).

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; the baseline for a no-param tool applies. No misleading hints about filtering are given, which is consistent with the empty 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 ('List') and resource ('skill bundles'), then defines what a bundle is with a concrete example ('a morning routine'). This implicitly separates it from list_skills, but it never names the sibling alternative explicitly, so differentiation relies on the reader knowing what a 'skill' vs 'bundle' is.

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 'install together with one prompt' hints that this is a discovery step preceding install_bundle, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is only implied from the resource description.

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?

readOnlyHint=true already establishes this as a safe read, so the description's main added value is naming the returned fields (tagline, category, audience, schedule, cost) in the absence of an output schema. It says nothing about result volume, ordering, or pagination for a tool that returns the entire catalog.

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 dense sentence with the enumeration scope front-loaded and zero filler. The trailing field list is useful rather than redundant given no 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 2-param, zero-required read tool with full schema coverage and a safety annotation, the definition covers purpose and return payload adequately. Only the behavior of an unfiltered full-catalog response (size, ordering) is left undocumented.

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%, including an enum explanation for audience, so the schema carries parameter meaning on its own. The description only echoes 'audience' and 'category' as output fields and adds no filtering semantics beyond it.

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?

Clear verb+resource: 'List every BotPlaza skill', plus an enumeration of the returned fields. It contrasts implicitly with get_skill (single item) and search_skills, but never names them, so differentiation is left to inference.

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 'List every... skill' implies the no-filter enumeration case, but nothing states when to prefer this over search_skills or how the optional filters interact with 'every'. Usage is only implied, not 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?

The readOnlyHint annotation already tells the agent this is a safe read operation, so the description's burden is reduced. It adds conceptual context about what a team is but says nothing about return contents, ordering, or whether the list is paginated or complete.

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 remainder used to disambiguate the domain term 'team'. Nothing is wasted or padded.

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 list operation with no output schema, the main ambiguity is what a 'team' is, and the description resolves that. The only residual gap is return shape, which is minor 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?

The tool takes zero parameters, so there is nothing for the description to document; the baseline for a 0-param tool applies. The description appropriately spends its words explaining the resource instead of inventing parameter detail.

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 ('List bot teams') and then defines the resource as groups of bots with distinct roles in a shared group chat. That definition distinguishes the object from sibling resources like bundles and skills, though it never names those siblings explicitly.

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 statement of when to call this versus get_skill, list_bundles, or search_skills, and no prerequisites or exclusions. Usage is only inferable from the verb 'List' and the fact that it takes no parameters.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It contributes the useful detail that matching spans four fields, but says nothing about result limits, ordering/relevance, or pagination behavior on a search surface where those matter.

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 front-loaded sentence with the verb, resource, and match scope; every clause carries information 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?

For a two-parameter read-only search with a fully described enum and no output schema, this is nearly sufficient. The only real gap is what a result looks like and whether results are ranked or capped, which is minor at this complexity level.

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 50%: the audience parameter is fully documented with its enum semantics in the schema, while query is undocumented there. The description partially compensates by naming the fields query matches against, but adds nothing on matching rules (exact vs substring, case sensitivity).

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 (search) plus resource (BotPlaza skills) and the searched fields (names, taglines, descriptions, tags), which is well beyond a tautology. It doesn't explicitly contrast with the sibling list_skills or get_skill, so the differentiation is inferable rather than stated.

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?

Keyword search implies its own use case, but the description never says when to prefer this over list_skills (browse everything) or get_skill (fetch one by id). No exclusions or prerequisites are stated, leaving usage to inference.

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