subscriptions

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

Given no annotations, the description carries the full burden. It discloses an important behavioral trait: the full account key is returned once, and only its SHA-256 and last four characters are retained. This adds valuable security context. However, it omits other behavioral aspects like idempotency, error handling, or rate limits.

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 extremely concise: two sentences with no redundant words. The first sentence delivers the purpose, and the second provides critical behavioral information. Every sentence 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 single-parameter tool with an output schema, the description covers the key behavioral context (key retention). It lacks usage guidelines and parameter semantics, but the existence of an output schema reduces the need to describe return values. Overall, it is mostly complete for 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 schema has 0% description coverage for the only parameter (account_ref), and the description does not explain what account_ref means, its format, or constraints. The phrase 'for bearer attribution' is vague and does not link to the parameter. No additional meaning is provided beyond the schema's type definition.

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 clearly states the action (create), the resource (a free account), and the specific purpose (bearer attribution). It also mentions key behavioral details about key retention. However, it does not explicitly differentiate from sibling tools, though the context of account creation is distinct from checkout, plans, and subscription 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?

No guidance is provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or context about when this tool is appropriate. The description lacks any 'use cases' or 'when to use' statements.

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 full burden. It discloses that the tool never charges and enumerates specific conditions that cause failure without creating a session. Could be more explicit about the return value, but the output schema likely covers that.

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 wasted words. First sentence states purpose, second adds critical constraints. Front-loaded and efficient.

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 simple tool with two parameters and an output schema, the description covers main behavioral aspects but misses parameter explanations. Fair given the available structure, but could improve.

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 input schema has 0% description coverage, and the description only hints at plan_id's role in failure conditions. account_ref is not explained at all. The description fails to add meaningful meaning beyond parameter names.

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 clearly states the tool prepares a Stripe-hosted subscription Checkout URL and explicitly says it never charges a card, differentiating it from related tools like record_subscription and customer_portal_link.

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 clear context about when the tool fails (draft plans, missing owner approval, etc.), but does not explicitly state when to use this tool versus alternatives. The failure conditions help guide the agent's decision.

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?

Discloses the tool never moves money, which is important context. However, with no annotations, it misses details like potential side effects (e.g., creating a Stripe portal session) or authentication requirements.

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 efficient sentences. The first directly states the output, the second adds behavioral context. No superfluous 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?

Adequate for a simple tool with output schema present, but missing parameter explanations reduce completeness. The description covers the core behavior but lacks detail on the input.

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?

With 0% schema description coverage, the description should explain the required account_id parameter. It only hints at 'bearer-owned' but doesn't specify what account_id represents or how to obtain 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?

The description clearly states the tool returns a Stripe billing portal URL and emphasizes it never moves money, distinguishing it from payment-related siblings like create_checkout_link. However, it doesn't explicitly name alternatives.

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?

Implies usage for customer management/cancellation via portal URL and hints it's not for payment operations, but no explicit when-not-to-use or alternative tool names are provided.

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 does not disclose any behavioral traits beyond the return list. Since no annotations are provided, the burden falls on the description, but it omits crucial details like read-only nature, idempotency, side effects, or whether the tool requires authentication. The listed items are purely declarative.

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 a single, concise sentence that efficiently lists the return items. It could be slightly improved by structuring the list, but it is not verbose and front-loads the key 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?

Given that the tool has no parameters and an output schema exists, the description adequately summarizes the output fields. It covers the key categories of information returned, though it lacks explanations or examples. It is sufficient for a zero-parameter tool with an existing 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?

There are no parameters, so the description does not need to add parameter meaning. Schema description coverage is 100% (vacuously), and the description provides context for what the tool returns. Baseline of 4 applies as the tool has zero parameters and the description adds value beyond 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?

The description clearly states the tool returns specific items: version, catalog digest, security posture, lifecycle policy, and capabilities. The verb 'return' is unambiguous, and the listed items differentiate it from sibling tools focused on accounts, plans, and subscriptions. However, it does not specify which agent is described (e.g., a default agent or the current user's agent), leaving a slight ambiguity.

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?

No guidance is provided on when to use this tool versus alternatives. The description only lists outputs without indicating context, prerequisites, or situations where this tool is appropriate. Sibling tools are unrelated in function, so the lack of usage direction is a notable gap.

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. Description mentions 'versioned catalog lineage' but doesn't clarify read-only nature, side effects, or other behavioral traits. Minimal transparency.

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?

Single sentence, no fluff. Could be more structured, but it's brief and to the point.

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?

Output schema exists, so return values are covered. But with only one param and no annotations, the description lacks completeness on context like plan type or lineage meaning.

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 0%. Description doesn't explain plan_id beyond its name; no format, constraints, or example. Compensation is insufficient.

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 clearly states the verb 'Get' and the resource 'exact monthly plan and its versioned catalog lineage', distinguishing it from sibling tools like list_plans.

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?

No guidance on when to use this tool versus alternatives (e.g., list_plans). No explicit when-not or context provided.

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. It describes the output content (prices, coverage, etc.) but does not explicitly state that the operation is read-only or idempotent, nor does it mention any side effects. The behavior is implied but not fully 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?

The description is a single, well-structured sentence of about 20 words. It conveys all essential information without waste, earning 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?

Given the tool has no parameters, no annotations, and an output schema exists (assumed to describe return structure), the description adequately covers the expected output. However, it does not mention if the list is paginated, sorted, or filtered, but such details may be in 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 input schema has zero parameters, so schema coverage is 100% by default. The description adds value by explaining what the output contains, which is the primary user interest for a parameterless listing 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?

The description uses the specific verb 'List' and clearly identifies the resource: the versioned monthly-seat catalog with details like prices, coverage, SHA-256, flags, and notice. It effectively conveys the tool's function, though it does not explicitly differentiate from the sibling 'get_plan' which likely retrieves a single plan.

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?

No guidance is provided on when to use this tool versus alternatives like 'get_plan' or 'create_checkout_link'. The description lacks context for appropriate usage or exclusions, leaving the agent to infer based on name and purpose.

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 full burden. It correctly indicates this is an aggregated read operation (returns data, no destructive actions). It adds context about not exposing identifiers. However, it could mention what happens if no active subscriptions or other edge cases.

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 wasted words. Front-loaded with the core return values. Perfectly concise for a simple aggregate tool.

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?

Given the tool's simplicity (no parameters, output schema exists), the description covers the essential return values (subscription count, MRR minor units, plan mix) and the privacy constraint. No additional context needed.

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 are no parameters, so schema description coverage is 100% trivially. Baseline for 0 params is 4. The description adds no parameter info because none exist, but this 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 clearly states the tool returns aggregate subscription metrics (count, MRR minor units, plan mix). The verb 'Return' and resource 'aggregate active live-mode subscription...' are specific. It distinguishes from siblings like usage_summary by specifying the exact metrics and noting no identifiers are exposed.

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 implicitly suggests it is for high-level summaries without account/Stripe identifiers, but does not explicitly state when to use it versus siblings like subscription_status or usage_summary. Missing when-not-to-use or alternative 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?

No annotations provided, so description carries full burden. It mentions 'idempotently activate' and 'newly created account' suggesting side effects like account creation, but doesn't fully disclose what gets modified, permissions needed, or error conditions. Lacks details on destructive vs read-only nature.

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 wasted words. First sentence describes the core action, second adds context. However, the second sentence is somewhat unclear, slightly reducing efficiency.

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?

Lacks details on return values (output schema exists but not described), error handling, prerequisites, and when to use vs siblings. For a non-trivial tool involving Stripe and idempotent activation, the description is too sparse.

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 has 0% description coverage for the single parameter. Description mentions 'stripe session/subscription' but doesn't provide format, examples, or constraints. Insufficient compensation for missing schema description.

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?

Description states a specific action: pull-verify and idempotently activate a subscription period. It distinguishes from siblings like subscription_status (which likely just reads) and create_checkout_link (which creates a link). However, the term 'pull-verify' is a bit jargon and 'A newly created account receives its key once' is cryptic, slightly reducing clarity.

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?

No explicit guidance on when to use this tool vs alternatives. The description implies it's for after a Stripe session, but doesn't say when not to use it (e.g., if only checking status) or mention alternatives among siblings.

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

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

With no annotations, the description only discloses that the account key is masked. It does not explicitly state the tool is read-only or non-destructive, nor does it discuss authentication or rate limits.

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, each adding value. The purpose is front-loaded and the masking detail is a concise behavioral note. No wasted 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?

Despite an output schema existing, the description omits crucial details about the parameter and does not explain what 'bearer-owned' means. It is incomplete for a simple 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?

The single parameter account_id is not described at all. Schema coverage is 0%, so the description adds no meaning beyond the schema, failing to explain its purpose, format, or allowed values.

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 clearly states the tool returns subscription lifecycle and current-period quota, using specific verb 'Return' and resource. It distinguishes from siblings like get_plan and list_plans by focusing on status and quota.

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?

No guidance on when or when not to use this tool versus alternatives. Lacks context about prerequisites or scenarios where other tools (e.g., get_plan) might be more 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?

With no annotations, the description should disclose read-only nature and authorization requirements. It mentions 'bearer-owned' but does not explicitly state it is a read operation, nor does it address side effects, rate limits, or required scopes.

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 a single sentence that concisely packs multiple qualifiers. It is front-loaded with the verb 'Return', but the jargon reduces readability. Still efficient with no wasted 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?

Given the output schema exists, the description adds domain-specific value (e.g., 'period-resolved', 'conservation totals'). However, it lacks parameter context and assumes domain knowledge, leaving gaps for new users.

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 description provides no explanation of the account_id parameter. It does not clarify format, source, or relation to the returned usage data.

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 clearly states the tool returns usage data with specific attributes (bearer-owned, period-resolved, included/overage, catalog lineage, conservation totals). It distinguishes from sibling tools like mrr_summary (revenue) and subscription_status (state), focusing on usage metrics.

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?

No guidance on when to use this tool versus alternatives. It does not specify prerequisites (e.g., having an account_id) or note that it only returns bearer-owned data. The description lacks explicit use-case context.

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