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. It does disclose return shape ('one line per connected service') and enumerates the status fields, but it does not explicitly say whether this call is read-only, whether it hits live services and could be slow, or whether any side effects are possible. The word 'status' implies a read operation, but nothing guarantees it.

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, information-packed sentence plus a two-word usage directive. No filler, no repetition of the title, and the output scope is front-loaded before the field list.

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 tool without an output schema, the description does enough: it says the output is one line per connected service, lists what appears on that line, and tells the agent to start here. It lacks post-call guidance about which sibling to use if specific status fields indicate problems, but that is not essential for a simple status overview.

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 zero parameters, and the schema is just an empty object, so the schema already covers everything needed. The 0-parameter baseline of 4 applies; there is nothing for the description to add about 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 identifies an aggregate 'Status of the whole stack' resource and lists the specific domains it covers (balances, blocked accounts, webhooks, deploys, errors, bounces, DB size). It clearly reads as an overview tool distinct from the granular stripe_* siblings, though it lacks a direct verb like 'get' or 'list' that would push it to 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?

'Start here' is an explicit invocation cue that frames this as the entry point for triage, which gives clear usage context. It does not explicitly name alternatives or state when to switch to sibling stripe_* tools, so it falls short of the strongest rubric level.

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 burden of behavior disclosure. It explains the chronological aggregation and time-window nature, which is helpful. However, it does not mention rate limits, permission requirements, output item shape, or behavior when many events exceed the limit.

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 just two sentences with no filler. The first sentence front-loads what the tool does, and the second adds a compelling use case. Every word 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 complex aggregator with no output schema and no annotations, the description is insufficiently complete. It does not describe the structure of returned timeline items, pagination behavior, or what happens when no sources match, leaving agents to guess about the actual response.

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 only 33% (only 'sources' has a description), and the description only hints at the time window through 'for the last N minutes.' It does not explain the 'limit' parameter or how to use 'sources' beyond the minimal schema note, leaving two of three parameters under-explained.

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 produces a chronological list of events across many types and services, making its purpose obvious. It differentiates itself from stripe-specific siblings by emphasizing 'every connected service' and enumerating diverse event types (deploys, errors, payments, etc.).

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 provides a clear use case: 'the fastest way to answer what changed before things broke.' It gives context for when this tool is appropriate but does not explicitly mention alternatives or when not to use it, such as when a stripe-specific event list would be better.

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 of behavioral disclosure. It describes what the tool returns (available and pending balance per currency) but does not state whether it is read-only, whether authentication is required, rate limits, or any other behavioral traits. This is a significant gap for a tool that likely performs a read operation.

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 delivers essential information efficiently, with the core resource (balance) and key distinction (platform vs. connected account) front-loaded. There is no redundancy or extraneous detail.

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 (one optional parameter, no output schema, no nested objects), the description covers the essential input semantics and output content. It does not mention auth or rate limits, but those are likely not necessary for a basic read-only balance query.

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 only provides a pattern for account_id, but the description clarifies its meaning: omitting it queries the platform account, while including it queries a connected account. This adds meaningful semantic detail and partially compensates for 0% schema description coverage.

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's resource (available and pending balance per currency) and scope (platform vs. connected account), making it easy to distinguish from siblings like list_accounts or get_account. However, it does not explicitly name sibling alternatives, so it falls just short of full differentiation.

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 implies when to use the tool (for balance queries) and explains the account_id distinction (no account_id for platform, provide account_id for connected account). It does not explicitly mention when not to use it or suggest alternatives, leaving usage guidance largely implicit.

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 burden. It discloses the kind of analysis performed (explaining why an account cannot charge or get paid out) and lists the categories of reasons it checks. However, it does not disclose whether this is a read-only operation, whether it makes any external calls, or what the output format looks like. For a diagnostic tool, the lack of output format detail is a gap, but the description does convey the behavioral intent.

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 front-loads the purpose ('Explain why a connected account cannot charge or get paid out') and then lists the specific diagnostic categories. Every word earns its place; there is no fluff or repetition of the 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 single-parameter diagnostic tool with no output schema, the description is reasonably complete. It tells the agent what problem this tool solves and what areas it covers. It could be improved by noting whether the output is a human-readable explanation or structured data, and whether it is read-only, but given the simplicity of the tool, the description covers the essential context.

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. The description names the single parameter implicitly: 'a connected account' maps directly to account_id. It also explains what the tool does with that account (diagnoses why it cannot charge or get paid out). With only one parameter and a clear pattern in the schema, the description adds enough context for an agent to understand what account_id represents.

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 ('Explain why') and names the exact resource ('a connected account') and the specific failure modes it diagnoses (disabled reasons, past-due requirements, capabilities, missing bank account, TOS). This clearly distinguishes it from sibling tools like stripe_get_account, which would retrieve account data but not synthesize a diagnosis.

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 implies when to use it: when a connected account cannot charge or get paid out. It does not explicitly name alternatives or say when not to use it, but the context is clear enough that an agent can infer this is the diagnostic tool for account-level charge/payout problems, versus stripe_diagnose_transfer for transfer-specific issues.

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 conveys that this is a diagnostic/read-oriented operation ('check what makes Connect transfers fail') and enumerates the behaviors it performs, such as comparing settlement currency, checking amounts, balance, payouts, and refunds. It does not explicitly say 'does not modify anything', but the framing strongly implies it.

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 dense sentence with the input format front-loaded and the failure checks following in a compact list. It is efficient and informative, though the long enumeration slows readability slightly.

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 diagnostics tool, the description covers the input format, purpose, and the specific checks performed. The main gap is the lack of any mention of output shape or return value, but that is not essential for correct invocation and the description is otherwise adequate.

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 already fully describes the single id parameter with the same 'tr_... or ch_...' format, so the description repeats rather than adds parameter semantics. The listed failure causes are useful context but not new meaning for the parameter itself. Baseline 3 applies because schema coverage is 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?

The description states a specific verb ('check') and resource (Connect transfers), and immediately scopes the input to transfer or charge IDs. It lists concrete failure categories, which clearly distinguishes it from sibling tools like stripe_diagnose_account and stripe_list_transfers.

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 'Given a transfer id ... or a charge id ...' provides a clear when-to-use context: use this when troubleshooting why a Connect transfer failed. It does not explicitly name alternatives or state when not to use it, but the diagnostic intent is evident.

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 must disclose behavior. It reveals that external accounts are returned with only last4 digits, which is a masking detail. However, it does not mention read-only nature, error handling, 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?

One concise sentence that front-loads the core purpose and enumerates the returned fields without waste.

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?

The description covers the main return data and scope (single account). However, it omits any error or edge-case information, but for a simple get operation it is fairly 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?

The description does not explain the account_id parameter. The schema provides a pattern, but the description adds no additional meaning, failing to compensate for the 0% schema coverage.

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 retrieves the full status of a single connected account and enumerates the key data (capabilities, requirements, external accounts with masking, dashboard type). It distinguishes from stripe_list_accounts which lists multiple accounts.

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 implies usage for a single account but does not explicitly address when to choose this over stripe_diagnose_account or when not to use it. No alternatives are named.

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 provided, the description carries the behavioral disclosure burden. It discloses that the payload is clipped escal, and that the response includes pending webhook count and the originating request. This goes beyond the schema, though it does not mention error behavior or authorization 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?

A single, front-loaded sentence conveys the tool's purpose and key behavioral detail. There is no redundant or filler content.

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 single-parameter get tool with no output schema, the description captures the essential returned fields and a notable behavior (clipped payload). It omits details like not-found handling, but these are less critical for a straightforward retrieval 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 description does not explain the event_id parameter beyond what the property name and pattern already imply. Since the coverage is low, the description was expected to compensate, but it does not address parameter meaning or format.

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 identifies a specific verb and resource: retrieving one Stripe event. It distinguishes itself from stripe_list_events by emphasizing 'one event' and enumerates the returned details (payload, pending webhook count, causing request).

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 clearly implies this is for fetching a single event rather than listing events, which is the main sibling alternative. It provides useful context about what the result contains, but does not explicitly state when not to use it or name 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It does add context beyond the title by naming the platform scope and the status fields returned, but it does not describe pagination, return shape, whether only summary fields are included, or any rate-limit/auth considerations.

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 one sentence, front-loaded with the primary action, and includes the key scope and status details without filler. Every phrase contributes useful 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?

For a low-complexity list tool with a single optional parameter, the description covers the core behavior and the returned status categories. However, with no output schema and no annotations, it leaves out return-format details, pagination behavior, and any mention of limitations, so it is adequate but not fully 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?

The schema has one optional 'limit' parameter with default, min, and max, but the description provides no parameter context. Since schema description coverage is 0%, the description does not compensate for the missing parameter semantics, though the single parameter is simple and self-explanatory.

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 and resource: 'List the connected accounts of this Stripe Connect platform.' It also clarifies the returned information ('status (charges, payouts, requirements due)'), which differentiates it from singular-account siblings like stripe_get_account and diagnostic tools like stripe_diagnose_account.

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 given about when to use this tool versus stripe_get_account, stripe_diagnose_account, or other list tools. The intended use is only implied by the verb 'list' and the resource name; there are no explicit exclusions or alternative recommendations.

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 recency, platform vs. connected-account scoping, and that destination, application fee, and attached transfer appear in results. However, it omits whether the operation is read-only, how pagination works, and the exact shape of the returned list.

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 and roughly 30 words deliver the essential scope and output highlights with no filler. The most important conditional behavior is front-loaded, and the output-field 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 simple two-parameter listing tool, this is close to sufficient: the account_id condition is clear and the output highlights are stated. But with no output schema and no annotations, the description should also clarify the result list shape and the pagination or ordering implied by 'recent' to be fully self-contained.

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 description adds real meaning to account_id by explaining that it selects a connected account and returns direct charges, which the schema's pattern alone does not convey. However, since schema description coverage is 0%, and limit is not explained in the description, the description only partially compensates for the missing parameter documentation.

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 identifies the resource (charges) and the key scope distinction: platform-wide charges by default, or a single connected account's direct charges when account_id is provided. The title supplies the verb, making the purpose unambiguous, but the description does not explicitly contrast this with sibling list tools such as stripe_list_transfers.

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 given about when to choose this tool over alternatives like stripe_list_transfers, stripe_list_payouts, or stripe_balance. The only usage hint is the conditional account_id behavior, which is parameter-level guidance rather than tool-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 behavioral burden. It adds useful semantics for only_undelivered and 'recent' scope, but it does not mention ordering, pagination, or the default limit behavior. It is not misleading, but the behavioral disclosure is incomplete.

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 compact and front-loaded: it states the scope first, then gives filter usage with concrete examples. Every sentence contributes useful information without repetition.

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?

The description is sufficient for basic invocation but lacks pagination/ordering details and does not mention stripe_get_event as the alternative for single-event lookups. Given no output schema or annotations, a bit more context would improve completeness.

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 description adds real meaning beyond the schema by explaining that type accepts both exact values and prefixes, and by defining only_undelivered. Limit is not described in prose, but its name and schema constraints make its purpose clear.

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 identifies this as a listing operation for recent Stripe events and explains the available filtering by type or prefix. It is readily distinguishable from stripe_get_event, which retrieves a single event.

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 gives clear context for when to use the tool: to list recent events with optional type/prefix filtering or undelivered-webhook filtering. It does not explicitly name alternatives or exclusions, but the context 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?

With no annotations, the description carries the behavioral burden. It adds useful context by stating that payouts travel from a connected account to its bank and by naming the returned fields, but it does not disclose pagination, ordering, read-only behavior, or failure conditions. This is a moderate contribution for a simple list 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?

A single sentence with no fluff that front-loads the resource and scope before listing notable output fields. It is appropriately sized for a straightforward list 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?

The description is not complete for an agent selecting among many sibling tools: it lacks alternative routing, parameter semantics for limit, pagination expectations, and return-shape details beyond three fields. Given no output schema or annotations, more context is 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?

Schema description coverage is 0%, so the description must compensate for the two parameters. It associates account_id with the connected account concept, but it never explains the limit parameter, its default, or the effect of the account_id pattern beyond what the schema already 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 title clearly says 'List payouts' and the description identifies the resource (payouts), scope (from a connected account to its bank), and useful fields (status, arrival date, failure reason). It is distinguishable from siblings like stripe_list_transfers, though it does not explicitly contrast itself with them.

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 about when to choose this tool over alternatives such as stripe_list_transfers or stripe_balance, nor any exclusion clauses. The connected-account phrasing implies its context, but no when-to-use or when-not-to-use guidance is 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?

No annotations are provided, so the description carries the full behavioral burden. It names transfer fields but does not state that this is a read-only listing, whether any state/status filters apply, what ordering or pagination is used, or what happens with large result sets. The side-effect profile and return behavior remain unclear.

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 compact and front-loaded with the resource and scope. The field list is terse but adds some useful context, and there is no redundant 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?

With no output schema and no annotations, the description is too thin for complete invocation guidance. It gives field hints but omits when to use it, parameter semantics, and list behavior such as ordering, pagination, and default limits.

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 description does not explain limit, since_days, or destination; it lists response fields rather than parameter semantics. The schema covers since_days and destination, but limit has only default/min/max, and the description adds no meaning for any parameter.

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 clear resource ('transfers') and scope ('from the platform to connected accounts'), and the title supplies the verb 'List'. It is distinguishable from charges/payouts/balance by naming transfer-specific fields. It does not explicitly contrast with stripe_diagnose_transfer, but the list-vs-diagnose distinction is reasonably 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?

There is no guidance about when to use this tool versus alternatives. Sibling tools such as stripe_diagnose_transfer and stripe_list_payouts are not mentioned, and the description gives no conditions or exclusions that would help an agent choose among them.

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, and the description does not disclose any behavioral aspects such as whether it performs a read-only operation, potential rate limits, or how the list is ordered. It is a simple statement without additional context, leaving the agent without safety or performance expectations.

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 concise and clear, but it lacks structure. It is a single sentence that does not front-load any critical details beyond the resource. It is not verbose, but also not particularly well-structured for quick scanning.

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 simplicity and no output schema, the description could mention the purpose of listing endpoints (e.g., to inspect configuration, troubleshoot delivery) and perhaps note that no filtering is possible. It is incomplete for an agent that needs to understand the value of this tool in context.

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 0 parameters)Skip, so the description need not explain parameter details. The schema coverage is 100% (vacuously), and the description adds a bit of context about the resource type. Scores high because there is no semantic burden on the 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?

The description states the purpose: listing webhook endpoints of the platform, but it is somewhat generic and could be more specific about what distinguishes it from other list tools. It does not explicitly mention filtering or pagination, but the resource is clearly identified as 'webhook endpoints'.

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 use this tool versus alternatives. The sibling tools include other list resources, and the description doesn't mention any context or exclusions. An agent is left without any direction on when this is the appropriate choice.

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