tigertiger

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

With no annotations, the description carries the full burden and usefully discloses the 'ungated' access condition (works for all users including Free/vault-only), which an agent needs to know before recommending it. It does not describe return behavior, but the presence of an output schema lowers that burden.

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 core capability and its routing preference are front-loaded, and the trigger list, while long, directly serves selection. Slightly list-heavy but every line 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 zero-parameter, output-schema-backed discovery tool, the description covers what it returns, when to prefer it over the sibling, who can call it, and the intents that map to it. Nothing an agent needs to call it 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. No semantic gap exists.

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 object ('Show everything on the user's TigerTiger plan — tools, trigger phrases, and how sessions work') and immediately differentiates from the sibling help tool by naming cos.help() as the alternative. An agent can distinguish this from 'help' or 'my_account' 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?

Explicitly names the alternative ('Preferred over cos.help() for plan-wide questions') and supplies the selecting condition plus an enumerated set of trigger phrases covering the exact user intents this should serve. Routing 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?

No annotations are provided, so the description carries the full burden, and it does disclose that this is an interactive guided interview rather than a one-shot operation. That is useful behavioral context. However, it doesn't state what the tool returns, whether it is read-only or mutating, or what happens at each stage of the interview.

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 core description is two tight sentences with the action front-loaded. The 'Args:' block is boilerplate that repeats schema information, slightly diluting the otherwise efficient prose.

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 an interactive multi-stage tool, the description covers purpose and method but omits what the agent should expect at each interview stage and what the interaction produces. Since an output schema exists, return-value details are not required, but the description still leaves the agent underprepared for running the interview.

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. It does explain the single parameter's meaning and that it is optional and may be left empty, which is genuinely useful. But it doesn't clarify format expectations beyond 'notes', and with only one optional param the baseline is naturally high.

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 action (prepare a monthly EO Forum 5% reflections update) and its method (a guided interview covering Work, Family, Personal). It clearly distinguishes the tool from generic siblings like help or capabilities, which are utility tools. The only gap is that 'EO Forum 5% reflections' assumes domain knowledge the agent may not have.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. The description implies a monthly cadence but doesn't say what triggers the tool or what state the user must be in. An agent would have to guess when this is appropriate.

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 carries the full behavioral burden. 'List' implies a read-only, side-effect-free operation, but the description never confirms this or says anything about cost, latency, or side effects. For a zero-param informational tool the risk is low, but the disclosure is implicit rather than stated.

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 tightly written sentences, front-loaded with the purpose before the call/no-call guidance. Every sentence — including the examples — earns its place by disambiguating trigger conditions.

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 zero parameters, full schema coverage, and an output schema that documents the return shape, the description covers everything needed to invoke correctly. The only gap is that it never positions itself relative to the 'capabilities' and 'strategy_map_help' 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 tool takes no parameters, which sets the baseline at 4. There is nothing for the description to clarify beyond that, and schema coverage is reported at 100%.

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 (work modes available in the TigerTiger Chief of Staff MCP), so the agent knows exactly what comes back. It does not differentiate itself from the similarly-named sibling 'capabilities' or 'strategy_map_help', leaving some potential confusion unresolved.

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 states when to call with three concrete user-utterance examples, and equally explicitly states when NOT to call ('Do NOT call this for general Claude capability questions'). This is the strongest part of the definition.

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 supplied, so the description carries the full burden and does disclose meaningful behavior: the tool is ungated and works for all users including Free/vault-only, and results are grouped by pack with per-skill usage hints. It still does not explicitly state that it is a non-mutating read or whether any rate/auth limits apply, keeping it below 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?

Front-loaded with the core action in the first sentence, followed by the return shape and availability note. The trigger-phrase list is longer than strictly necessary but earns its place for routing, so the description is efficient overall.

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-style listing tool with an output schema already defined, the description supplies what the schema cannot: what the listing contains, how it is organized, and that it is available to all tiers. Nothing needed to invoke it 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics for the description to clarify or omit.

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 ('Show all TigerTiger skills') plus scope ('available on the user's plan, grouped by pack'), so the agent knows exactly what comes back. It does not explicitly differentiate itself from the sibling 'capabilities', which is the one plausible overlap, so it stops 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?

Provides concrete trigger phrases ('list skills', 'what skills do I have', etc.) and an availability condition ('ungated — works for all users including Free (vault-only)'). It gives clear when-to-use context but never names an alternative tool or a when-not-to-use case.

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 carries the full burden. It does disclose real behavior beyond the schema: the tool is ungated for Free users and returns a friendly response when the key isn't recognized. However, it says nothing about auth requirements, rate limits, or what happens with an unknown key beyond 'friendly', leaving meaningful behavioral gaps for a no-annotation 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?

Purpose and scope are front-loaded in the first sentence, followed by gating behavior and trigger phrases. It is efficient, though the parenthetical about capabilities() and unrecognized keys is somewhat wordy for the value it adds.

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 lookup with an output schema, the description covers everything an agent needs: what it returns, who can call it, and when to trigger it. Return-value documentation is correctly left to the output 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The listed fields (plan, seats, users) describe the response shape rather than inputs, and the output schema already covers returns.

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 ('Show account info') and enumerates the returned fields (plan, seats, users), so the agent knows exactly what the tool surfaces. It references capabilities() but only to explain gating parity, not to discriminate when this tool should be chosen over siblings like upgrade_link or capabilities.

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 'Triggers on:' list gives concrete invocation phrases ('what's my plan', 'my account', 'my subscription', 'account info') plus an explicit eligibility condition ('works for all users including Free'). That is strong positive guidance, but there is no when-not guidance or named alternative for adjacent questions such as upgrading a plan.

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, but for a zero-parameter listing tool the risk surface is minimal. 'List' implies a safe read, though the description does not explicitly confirm read-only behavior or the format of the result. Since an output schema exists, return values need not be explained here.

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 no filler. Every word earns its place for a tool this simple.

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 informational tool with an output schema already present, the description is nearly sufficient. The only gap is the lack of any routing hint against the similar 'help' and 'capabilities' 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 tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies for a parameterless tool.

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 ('modes available in the TigerTiger Strategy Map'), so the agent knows it returns a set of mode names. It does not, however, distinguish itself from siblings like 'help' or 'capabilities', which could plausibly overlap in intent.

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 guidance on when to call this versus the sibling 'help' or 'capabilities' tools, nor any stated precondition or exclusion. The agent must infer usage from the description alone.

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 does the important part well: it discloses that no charge occurs server-side and that user confirmation is required. It omits auth/permission requirements and link expiry/one-time-use semantics, which would matter for a billing flow.

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 key facts (what it returns, that it never charges) are front-loaded in the first three lines, followed by an Args block. The Args heading is somewhat verbose for one parameter, but nothing is padded or redundant.

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 present, the description needn't detail return values, and its behavioral note about the URL and confirmation step fills the safety gap left by missing annotations. The only shortfall is unaddressed auth requirements for a billing-adjacent 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 description coverage is 0% and the schema declares no enum, so the description must compensate — and it does, defining the allowed values ('monthly' or 'annual') and the default ('monthly'). It adds no formatting constraints beyond that, but for a single string param this is sufficient.

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 a Stripe Checkout link to upgrade to Pro') and immediately scopes it ('Returns a URL only — never charges directly'), which no sibling does. An agent can distinguish this from billing-unrelated siblings like my_account or capabilities at a glance.

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 explains the flow context: the link must be opened and confirmed by the customer, implying this is the initiating step for an upgrade rather than a direct purchase. It does not name an alternative tool or state exclusions, but the sibling list contains no competing upgrade/checkout tool, so the gap is small.

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