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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the HTTP method (GET), read-only nature, and rate limit – useful safety information. However, it doesn't specify what data the overview includes, error behavior, or pagination, leaving significant gaps for an agent to infer.

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, compact sentence that front-loads the purpose and includes key constraints (rate limit, read-only). It is free of fluff and easy to parse, though it omits param details that could have been added concisely.

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 two optional parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the parameter semantics or what the overview return value contains. An agent cannot confidently call this tool without guessing at parameter meaning, so the definition is under-specified.

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 two optional parameters (to, from) with zero description coverage. The tool description gives no explanation of their meaning, format, or default behavior. An agent has no idea these likely represent a date range, nor how to format them. This is a critical gap since the schema offers no help.

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 fetches a 'delivery overview' – a specific resource with a clear action. It doesn't explicitly contrast with sibling tools like getAnalyticsTimeseries, but the word 'overview' implies aggregate data versus time-series, so the purpose is reasonably distinct.

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 mentions a rate limit and the read-only nature, which are usage constraints, but it does not explicitly state when to prefer this tool over alternatives (e.g., when you need a summary vs. detailed timeseries). It provides some context but no explicit when-to-use or when-not-to-use 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 provided, the description must disclose behavioral traits. It explicitly mentions a rate limit (100 requests per 1m) and read-only nature, which are critical for safe invocation. However, it omits details about response format or any edge cases, but the key operational constraints are covered.

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, compact sentence that front-loads the primary action and includes crucial operational details (rate limit, read-only) without redundancy. It is appropriately sized for the tool's simplicity.

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 tool has no output schema, no annotations, and undocumented parameters. The description only provides high-level purpose and rate limit, but it does not explain what metrics are returned, how parameters affect the query, or any usage constraints. For a tool with three optional parameters, this is insufficient for an agent to invoke it correctly.

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 lists three string parameters (to, from, interval) with no descriptions, and the description does not elaborate on their meaning, format, or expected values. With 0% schema description coverage, the description fails to compensate, leaving agents without any guidance on how to set these parameters correctly.

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 ('Get time series metrics') and identifies the resource (analytics timeseries). It also notes the read-only nature and HTTP endpoint, which helps differentiate from other tools. However, it doesn't explicitly contrast with getAnalyticsOverview, which might cover similar analytics data.

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, such as getAnalyticsOverview. The description simply states what it does without providing context on selection criteria or exclusions. An agent would have to infer usage from the tool name 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only ('GET /postframe/api-keys') and includes a rate limit (100 requests per 1m), which is valuable context. It does not mention response format or error behavior, but for a simple list operation this is sufficient.

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, tight sentence that packs purpose, rate limit, and read-only nature. Every word earns its place, and the most important info (the resource) is front-loaded.

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, output-schema-less read tool, the description covers the essentials. However, the existence of a similarly named sibling ('listApiKeys') creates an unresolved ambiguity about when to use which. This omission is a meaningful gap for an agent navigating these tools.

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 has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter details because none exist. Nothing more is needed.

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 verb ('List') and resource ('API keys'), with the HTTP endpoint for precision. However, it does not differentiate from the sibling tool 'listApiKeys', which appears to serve the same purpose. This ambiguity prevents a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool over any alternative. The rate limit is mentioned but is a constraint, not a usage guideline. No exclusions or conditions are given. This fails to help the agent choose between the two similar list tools.

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. It discloses the HTTP method (GET), read-only nature, and rate limit (100 requests per 1m), which is helpful. However, it does not mention pagination, response shape, or any other behavioral details.

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 compact sentence that front-loads the core action and includes the rate limit and endpoint. Every element earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool, the description is mostly complete, but it lacks any mention of pagination or response format. The rate limit is disclosed, but an agent might still wonder about result ordering or 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 tool has zero parameters, so there is no schema burden to compensate for. The description's mention of the endpoint and rate limit adds context beyond the empty schema, making this a solid score.

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 verb ('List') and resource ('audiences'), and the parenthetical 'Read-only (GET /postframe/audiences)' reinforces the operation. It is distinguishable from siblings like getAudiencesById and getAudiencesByAudienceIdBroadcasts, though it does not explicitly name 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?

The description implies usage by identifying the endpoint and read-only nature, but it does not explicitly state when to prefer this over sibling tools like getAudiencesById or listCoupons. The rate limit is a useful constraint but not a usage guideline.

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 discloses the read-only nature (GET method) and a specific rate limit of 100 requests per minute, which is meaningful behavioral context beyond the schema. However, it does not mention pagination, error responses, or what happens if the audienceId is invalid, leaving some transparency gaps for a listing 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?

The description is two concise sentences, front-loaded with the core action. It adds only relevant metadata (rate limit and read-only) without unnecessary verbosity, making it efficient and well-structured for an agent to parse quickly.

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 single parameter and no output schema, the description includes the rate limit and read-only policy but omits whether the response is paginated or the shape of the broadcast objects. For a listing endpoint, pagination behavior is commonly important to know, but the description does not address it. The provided context is adequate for a simple call 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?

Schema description coverage is 0%, so the description must compensate. The only parameter, audienceId, is not described in the schema, and the description only implicitly references it via 'for an audience' without explaining its format, required shape, or any constraints. This is minimal added meaning and does not fully compensate for the lack of schema 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 states the action ('List broadcasts') and the resource ('for an audience'), matching the tool name precisely. It distinguishes this tool from the many sibling list/get tools by specifying the audience-scoped broadcasts, so an agent can recognize its specific function without 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?

The description provides clear context: it's read-only and for listing broadcasts of a specific audience. It does not explicitly state when not to use it or name alternatives, but the purpose is unambiguous and no sibling tool overlaps directly. A short exclusion note would earn a 5, but the current clarity is sufficient.

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 disclosure burden. It explicitly discloses the HTTP method (GET), that the operation is read-only, and the rate limit (100 requests per 1m), which is useful operational context. It does not mention auth or error behavior, but for a simple read operation this is reasonably 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 compact sentence that front-loads the core purpose, then adds rate limit and method information. Every element earns its place 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 simple one-parameter read-only GET tool with no output schema, the description is largely complete: it gives the endpoint, the rate limit, and the read-only behavior. It omits auth/error details, but nothing critical is missing for an agent to invoke it with an ID.

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 endpoint '/postframe/audiences/{id}' clarifies that the single 'id' parameter is a path parameter identifying the audience, adding some meaning beyond the bare string schema. However, it does not define the ID format or any value constraints.

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: 'Get audience details', and reinforces it with the exact endpoint 'GET /postframe/audiences/{id}'. It clearly targets a single audience rather than a list, though it does not explicitly contrast itself with sibling tools like getAudiences.

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 guidance on when to use this tool versus alternatives such as getAudiences or getAudiencesByAudienceIdBroadcasts. The only context provided is the rate limit and the read-only nature; no use case or selection criteria is stated.

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 burden of disclosing behavior. It explicitly states 'Read-only' and includes the HTTP method and rate limit (100 requests per 1m), which are meaningful behavioral details beyond the tool name.

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 compact sentence with no filler. The core purpose is front-loaded, followed by rate limit and read-only/endpoint context. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only status endpoint, the description provides the route, safety profile, and rate limit, which is sufficient to call it. It could be more complete by clarifying what 'subscription status' returns or how it relates to listSubscriptions, but no output schema exists and the operation is simple.

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 has zero parameters and the empty schema fully describes them, so the baseline is 4. The description adds nothing parameter-specific, but none is needed.

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 ('Get') and resource ('subscription status') and includes the endpoint path, so an agent can tell it is a read operation for subscription billing data. However, it does not explicitly distinguish it from sibling tools like listSubscriptions, so it is not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives such as listSubscriptions, getUsageQuota, or getSubscriptionInvoicePdf. The rate-limit note is operational context, not usage 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 provided, the description carries the behavioral disclosure burden. It explicitly states the operation is read-only, shows the HTTP method, and discloses the rate limit of 100 requests per 1m. It does not describe response content or authorization requirements, but for a zero-parameter read-only status check this is strong 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?

One compact sentence packs the verb, resource, rate limit, safety profile, and endpoint with no filler. Every clause earns its place, and the most important identifying information appears first.

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 status check, the description provides the essential request context: what to retrieve, the endpoint, the rate limit, and the safety level. The only minor gap is that it does not define what values or fields 'status' may contain, but there is no output schema requiring explanation and invocation remains unambiguous.

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 has zero parameters, and the schema already has 100% coverage of nothing, so there is no parameter documentation burden. The description reinforces the operation by tying it to the GET endpoint, which is sufficient at the baseline 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?

The description names a specific verb ('Get'), a specific resource ('the tenant's Stripe Connect account status'), and gives the concrete endpoint (GET /paygate/connect/account). This makes it immediately distinguishable from siblings like getConnectBalance, which target a different resource.

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 usage context is implied by the wording: call this when you need the tenant's Stripe Connect account status. However, it does not explicitly mention alternatives, exclusions, or conditions under which another tool would be preferable, so the guidance is adequate but 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?

With no annotations provided, the description carries the full burden and does well by disclosing the rate limit ('100 requests per 1m') and read-only nature. It also names the HTTP method and endpoint. It does not describe response format or potential error cases, but for a simple read-only balance lookup the key behavioral traits are covered.

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 that delivers the resource, the endpoint, the read-only safety profile, and the rate limit without fluff. Every component earns its place and the most important information is front-loaded.

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, no-output-schema tool, the description is largely complete: it states what is returned (balance), how to access it (endpoint), safety (read-only), and usage limits (rate limit). The only omission is a clearer picture of the response shape, but the low complexity and named resource keep this from being a significant gap.

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 the baseline is 4. The description still adds useful context by clarifying that the balance belongs to the connected account, making the implicit auth context concrete. There are no parameter semantics to explain beyond this.

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: 'Get the connected account's Stripe balance', reinforced by the exact endpoint 'GET /paygate/connect/balance'. This clearly distinguishes it from sibling tools like getConnectAccount, which presumably returns account details rather than balance.

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 makes the intended use obvious from its resource name, but it does not explicitly state when to use this tool versus an alternative or when not to use it. It gives no exclusion criteria or sibling comparisons, though the unique balance-focused purpose makes misuse unlikely for a zero-parameter getter.

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 full behavioral burden, and it does disclose two important traits: the rate limit (100 req/min) and the read-only nature ('Read-only'). These are genuinely useful operational behaviors beyond what any schema shows. It falls short only on return-format/pagination behavior, which is not disclosed in a world with no annotations and no output schema.

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 compact sentence front-loads the core purpose and packs in the rate limit and read-only disclosure efficiently. No filler. The only mark against it is that critical behavioral info is crammed into parentheticals rather than being fully integrated, and the missing parameter info is an omission rather than a style issue.

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 paginated list tool with no output schema and no annotations, the description covers the rate limit, method, and endpoint, but leaves out parameter semantics and any statement about what the response contains. The tool is simple enough that some gaps are tolerable, but in a no-annotation environment the description should do more.

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 mentions none of the three parameters (limit, offset, search). An agent sees raw param names with no types, formats, defaults, or semantics. In a no-annotation context with 0% schema coverage, the description fails to compensate, leaving the agent to guess at 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 opens with 'List contacts,' a clear verb+resource that distinguishes this from getContactsById (a single-resource fetch). The endpoint 'GET /postframe/contacts' reinforces the listing semantics. It could be slightly more specific about what a contact is, but the core purpose is unambiguous and distinguishable from siblings.

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 vs. alternatives. The sibling list contains many list/get tools, and the description never contrasts with getContactsById or mentions pagination/search use cases. An agent can infer 'use to list contacts' but receives no explicit when-to-use / when-not-to-use direction.

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 discloses that the operation is read-only and provides a rate limit (100 requests per 1m), which is valuable given no annotations are present. However, it does not mention error handling, authentication requirements, or behavior when the contact is not found. For a simple GET, this is partially transparent but not comprehensive.

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 very concise, with a single sentence that leads with the purpose. The rate limit and read-only status are included in parentheses, which keeps it compact. While the structure is a bit jumbled, it is efficient and free of extraneous 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 tool with one simple parameter and no output schema, the description should at least explain the parameter and likely return behavior. It does neither. The absence of usage guidance and parameter explanation leaves an agent with insufficient context to call the tool correctly, despite the clear naming convention.

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 required string parameter 'id' with 0% description coverage. The tool description does not explain what the id represents (e.g., the contact's unique identifier). The endpoint hints at it, but the description adds no semantic value beyond the schema, failing to compensate for the lack of schema 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 states a clear verb and resource ('Get a contact') and includes the endpoint with the {id} placeholder, which signals it retrieves a single contact by ID. This distinguishes it from the sibling getContacts tool, though it could be more explicit about the 'by ID' aspect.

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 guidance on when to use this tool versus alternatives like getContacts. The name and endpoint imply it is for fetching a specific contact, but the description does not state this or mention any conditions (e.g., 'use when you have the contact ID'). No exclusions or alternative routing 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states read-only behavior, the HTTP GET method, and a rate limit of 100 requests per minute. It does not explain error handling or pagination, but the provided constraints are useful.

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 compact sentence with the core function first, followed by rate limit and read-only/endpoint context. There is no filler, and every clause 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?

Adequate for basic invocation: the agent knows what the tool does, which parameter to supply, and that it is read-only with a rate limit. However, with no output schema and no annotations, the description omits response shape, pagination behavior, and error conditions such as a customer not being found.

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 bare 'email' string in the schema. It does this by showing email as the path parameter in GET /paygate/customers/{email}, which adds meaningful endpoint context beyond the schema. It stops short of describing email format or encoding requirements.

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 customer's transaction history', with the email path in the endpoint making the scope clear. It does not explicitly name sibling tools like listTransactions or getTransactionById, but the email-scoped resource is enough to distinguish it.

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 when to use it: when you need a single customer's transaction history by email. It gives no explicit guidance on when not to use it or which alternative tool to choose, such as listTransactions for broader transaction queries.

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 states 'Read-only' plus the rate limit (100 requests per 1m), which are valuable behavioral traits beyond the schema. It does not disclose response format or error behavior, but for a simple GET-by-ID tool these are minor gaps.

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 efficient sentence that packs the endpoint, read-only nature, and rate limit without any unnecessary words. Every element earns its place and no reformatting is needed.

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 read-only tool, the description covers the core semantics and the rate limit, but with no output schema the response shape is left entirely undisclosed. Minor details about error responses or authentication would make it more complete, but it is adequate for basic invocation.

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 'id' parameter. It only says 'by ID' without explaining the format, source, or type of the expected identifier, leaving the agent to guess whether it is the dispute ID, payment ID, or some other key.

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 ('Get') and resource ('dispute by ID'), and includes the explicit HTTP method and endpoint. This clearly distinguishes it from listDisputes and other get-by-ID siblings without requiring the agent to inspect the 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?

The description implies usage when a single dispute ID is on hand, but it does not explicitly state when to use this tool versus listDisputes or other alternatives. The inclusion of the read-only HTTP method gives some context, but no direct exclusion or alternative 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 present, so the description carries the behavioral burden. It explicitly declares 'Read-only', states the HTTP method, and provides a rate limit (100 requests per 1m), all of which are useful. It does not mention response format or pagination, but the core safety profile is disclosed.

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?

Every piece of text earns its place: the operation, the rate limit, the read-only hint, and the endpoint. It is front-loaded with the core action and contains no filler or 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?

For a simple zero-parameter read-only list, the description covers the operation, method, and rate limit. It could add guidance on response shape or pagination, but the low complexity and existing details make the definition largely 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 input schema has no parameters and schema coverage is 100%, so there are no parameter semantics for the description to add. The baseline of 4 applies because there is nothing undocumented to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List domains', a specific verb and resource, and also names the exact endpoint 'GET /postframe/domains'. This clearly distinguishes it from the related sibling 'getDomainsById' and other list/get 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?

The description makes the use case clear: list all domains. It also signals this is a read-only operation via 'Read-only' and the GET method. It does not explicitly compare with getDomainsById, but the context is strong enough for a zero-parameter list tool.

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

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

With no annotations, the description carries the full behavioral burden and does well by explicitly stating 'Read-only' and 'rate limit: 100 requests per 1m'. It does not describe error cases or the response shape, but for a simple GET-by-ID tool the disclosed behavior is meaningful and sufficient.

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 compact sentence that packs in the operation, rate limit, readonly behavior, and endpoint. Every clause provides useful information and there is no redundancy.

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, read-only GET tool, the description provides enough invocation context: endpoint, rate limit, and safety profile. It does not describe the return payload, but 'details' implies the response, and the simplicity of the tool reduces the need for more.

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 describes `id` only as a required string with 0% description coverage, and the description adds little beyond the endpoint path containing `{id}`. The meaning of `id` is reasonably inferable from the tool name and resource, but the description could have explicitly clarified that it is the domain identifier.

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 verb and resource: 'Get domain details', and the endpoint pattern `GET /postframe/domains/{id}` reinforces that this is a single-resource fetch. It does not explicitly contrast with the sibling `getDomains` list tool, but the tool name and path make the distinction fairly clear.

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 is given about when to use this tool versus alternatives such as `getDomains`. The only context is the name and endpoint, which imply by-ID lookup, but the description itself does not state usage criteria or 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?

With no annotations, the description carries the full disclosure burden. It usefully mentions the rate limit and that the operation is read-only via GET, but it does not discuss pagination behavior, defaults, authentication, or response format.

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 no filler. However, the brevity comes at the cost of omitting parameter semantics and usage context.

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 six-parameter list endpoint with no output schema and no annotations, the description is incomplete. It gives rate-limit and read-only context but leaves filter semantics, date formats, and pagination entirely unexplained.

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 across six parameters, and the description adds no parameter information. An agent cannot infer the meaning of 'to', 'status', 'from_date', 'to_date', 'limit', or 'offset' from this 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 states a specific verb ('List') and resource ('emails') and provides the endpoint. It clearly implies a collection operation distinct from getEmailsById, though it does not explicitly name any sibling alternative.

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 other list/get siblings. 'List emails' implies a purpose, but there are no conditions, exclusions, or alternative tool 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?

No annotations are present, so the description carries the burden of behavioral disclosure. It reveals the rate limit (100 requests per 1m), read-only status, and GET method, which give useful safety and cadence signals. It does not cover error behavior or return shape, but for a simple read operation this is mostly sufficient.

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 compact sentence with the primary action front-loaded. Every clause adds value: the action, the rate limit, and the read-only endpoint. No filler or redundant explanation.

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-required-parameter read-only tool, the description provides the endpoint, rate limit, and method. It lacks explicit output expectations and alternative usage guidance, but those gaps are minor given the simplicity of the operation.

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 only the id parameter with 0% description coverage. The description maps id to the email resource via the endpoint path, but it does not explain the id format, constraints, or scope. It only partially compensates for the lack of schema 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 states a specific verb and resource: 'Get email details' and the endpoint GET /postframe/emails/{id}. Its singular 'by id' focus distinguishes it from sibling list-style tools such as getEmails. The read-only designation adds further 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?

Usage is implied by 'Get email details' and the required id parameter, but the description does not explicitly say when to use this tool versus alternatives like getEmails. No when-not-to-use or alternative routing 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?

With no annotations provided, the description carries the full behavioral burden. It discloses that the operation is read-only, specifies the HTTP method and path (GET /paygate/settings), and gives a concrete rate limit (100 requests per 1m). This is meaningful behavioral context beyond the empty schema.

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 with the core purpose front-loaded and useful constraints (rate limit, read-only) appended. Minor redundancy exists between 'Read-only' and 'GET', but the overall structure is tight and information-dense.

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 GET with no output schema, the description provides enough context to call the tool correctly: the resource, the endpoint, and the rate limit. It does not describe the response structure, but the lack of parameters and output schema lowers the burden; still, a note about authentication or response contents would have pushed it higher.

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 has zero parameters, so there is nothing for the description to clarify about arguments. The baseline for 0 params is 4, and the description appropriately focuses on what the tool returns rather than parameter usage.

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-and-resource pattern: 'Get merchant settings and fraud rules.' This makes the tool's function clear and the mention of 'fraud rules' distinguishes it from generic getters like getSettings or getSettingsOnboarding, 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?

Usage is implied rather than explicit: the description tells the agent this retrieves merchant settings and fraud rules, so an agent can infer when to use it. However, it provides no alternatives, exclusions, or direct comparison with the many similar getters in the sibling list.

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 discloses that the tool is read-only and includes the HTTP method (GET), which is useful behavioral context. It also mentions a rate limit of 100 requests per 1m, which is a meaningful operational constraint. However, with no annotations provided, the description carries the full burden and could add more context about what 'processing volume' includes or whether it reflects live or cached data.

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 core purpose, then adds the rate limit and read-only/endpoint details. Every element earns its place, and there is no wasted wording.

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 tool with no output schema, the description is largely complete: it names the resource, the endpoint, the read-only nature, and the rate limit. The only minor gap is that it doesn't describe the response shape or units of the volume, but the absence of an output schema makes that less critical.

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 has zero parameters, so the schema provides no parameter semantics to rely on. The description compensates by clearly stating the resource and scope (tenant's month-to-date processing volume), which is sufficient for an agent to understand what the tool operates on. A baseline of 4 is appropriate for a no-parameter 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 clearly states the tool gets the tenant's month-to-date processing volume, with a specific verb and resource. It distinguishes itself from siblings by naming the endpoint (GET /paygate/me/volume), though it doesn't explicitly contrast with similar analytics/usage tools like getUsageQuota or getPaymentStats.

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 context by identifying the resource as the tenant's month-to-date processing volume, but it does not explicitly state when to use this tool versus alternatives like getUsageQuota or getPaymentStats. The rate limit is mentioned, which is useful operational guidance, but no exclusions or alternative routing 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?

There are no annotations, so the description carries the full transparency burden. It usefully discloses read-only behavior and a 100-requests-per-minute rate limit. However, it does not describe the response shape, the exact meaning of 'stats', or any 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?

The description is very short and front-loads the tool's purpose and rate limit. The parenthetical structure is slightly telegraphic, but every phrase adds useful information and there is no wasted text.

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 zero-parameter GET endpoint, the description is mostly adequate. However, with no output schema and no mention of what the stats represent or whether they cover a time range, an agent may be uncertain about how to interpret the 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?

The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to add. The baseline of 4 applies here since the tool takes no parameters and thus needs no parameter-level clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the endpoint and marks it as a read-only GET operation, so an agent can tell it retrieves payment statistics. It does not explicitly enumerate what metrics are included or distinguish it from analytics siblings like getAnalyticsOverview or getMonthToDateVolume.

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 when-to-use or alternative guidance is provided; the only usage-related information is the rate limit and read-only status. With many sibling analytics and transaction tools, an agent cannot tell when to choose this over getTransactionById or getAnalyticsOverview.

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 and handles it well by explicitly stating 'Read-only' and the rate limit (100 requests per 1m). This goes beyond the schema and helps the agent understand safety and throttling, though it omits response shape and pagination details.

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 compact sentence that front-loads the action and packs the key constraints (rate limit, read-only, endpoint) with 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 parameterless GET endpoint, the description provides the essential context: resource, HTTP method, read-only behavior, and rate limit. It lacks a note about response format and does not address the overlap with listProviders, but it is sufficiently actionable for a simple list call.

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 and 100% description coverage, so there is nothing for the description to add. The baseline of 4 applies because the tool takes no arguments.

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 verb and resource ('List providers') and gives the endpoint. However, it does not distinguish getProviders from the sibling listProviders, which appears to target the same action.

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 choose this tool rather than listProviders or other provider-related tools. The description simply states what it does, leaving the agent to infer the appropriate context.

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 mention the rate limit and that it's read-only, which is useful behavioral context. However, it does not disclose any other behaviors such as authentication requirements, response format, or potential errors, which would be important for an agent to know.

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, with two short sentences. It front-loads the core purpose ('Get tenant settings') and then includes the rate limit and HTTP method in a compact form. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter read-only tool, the description covers the core. However, it lacks details about return format, authentication, or error handling, which might be expected for a settings endpoint. The rate limit is useful, but more context could be added without being verbose.

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 has zero parameters, so the schema is empty. The description adds meaning by indicating the resource being fetched and the rate limit, which is more than what the schema provides. Since schema coverage is high (100% by default with no params), the baseline is 4, and the description adds a little extra context.

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 ('Get') and a resource ('tenant settings'), which is clear. However, it does not distinguish itself from the many sibling tools that also start with 'get' (e.g., getMerchantSettings, getSettingsOnboarding), so it lacks sibling 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 provides a clear context (fetching tenant settings) and notes the HTTP method (GET) and rate limit, which helps an agent know when to use it. However, it does not explicitly state when not to use it or mention alternatives such as getMerchantSettings, which might be a similar tool.

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 behavioral disclosure and does include read-only semantics, the HTTP GET method, and a rate limit of 100 requests per 1m. It does not describe the shape or possible values of onboarding status, but core non-obvious behavior is covered.

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 compact, front-loaded sentence; it places the purpose first and includes the useful endpoint and rate-limit in parentheticals without redundancy.

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 GET endpoint, the description is nearly complete: it provides endpoint, read-only nature, and rate limit. The only minor gap is not defining what an onboarding status value looks like, but this does not impede correct invocation.

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 required or optional parameters and the input schema is empty, so the description has no parameter details to compensate for. Baseline 4 is appropriate because no parameter ambiguity 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?

Description states a specific verb+resource: 'Get onboarding status', and reinforces it with the endpoint path '/postframe/settings/onboarding', which distinguishes it from generic siblings like getSettings and getMerchantSettings.

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, no exclusions, and no relationship to getSettings or other settings endpoints. Usage is only implied by the verb, not explained.

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 explicitly states no auth is required and it's read-only, which is helpful since annotations are absent. It also mentions the HTTP method and path, adding behavioral context beyond the schema.

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 two short sentences, front-loads the key fact (public, no auth), and includes all essential info 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?

For a zero-parameter, read-only health check, the description covers auth and method. It doesn't explain return values, but output schema is absent, yet for health checks, 'service health' implies a status payload. Adequate given 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 no parameters, so description doesn't need to compensate. However, it gives no info about response format, but for a health check, the description 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?

The description clearly states the tool checks service health, a specific resource, and distinguishes it from siblings which are all data-focused. It's not a tautology and provides a clear purpose.

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 it's for health checks but doesn't explicitly state when to use it versus other tools. Since it's a unique health check among siblings, context is enough, but no explicit guidance on when not to use it.

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 behavioral disclosure. It states the operation is read-only, shows the HTTP method (GET), and discloses a rate limit of 100 requests per 1m. These are meaningful behavioral details, though it does not cover auth requirements or error behavior.

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 entire description is one dense, front-loaded sentence containing the action, resource, endpoint, rate limit, and read-only nature. There is no filler or redundant 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?

For a simple one-parameter read-only download with no output schema, the description is largely complete: it names the resource, the endpoint, the rate limit, and the fact that the result is a PDF. It lacks only minor context such as authentication expectations or how to obtain the invoiceId, but this does not seriously impair usability.

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 undocumented invoiceId parameter. It does not explain what invoiceId represents, where to obtain it, or its format; it appears only in the endpoint path. The parameter name is self-explanatory, but the description adds no semantic value 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?

The description uses a specific verb ('Download'), a precise resource ('branded PDF of the tenant's own platform subscription invoice'), and an explicit endpoint. This clearly distinguishes it from sibling list/get tools, which focus on data objects rather than PDF downloads.

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 'tenant's own platform subscription invoice' gives clear context for when this tool applies, and the endpoint path '/paygate/me/invoices/{invoiceId}/pdf' reinforces the scoping. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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 usefully discloses that the operation is read-only, uses GET, and has a rate limit of 100 requests per minute. However, it does not disclose pagination behavior, default values, possible errors, or what the response contains.

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: the core purpose appears first, followed by essential rate-limit and read-only information. There is no redundant filler; every phrase contributes operational value.

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 no annotations, no output schema, and 0% parameter coverage, the description is too sparse to be complete. It covers the basic operation and rate limit, but lacks parameter semantics, pagination/defaults, and return-shape expectations, which an agent would need to call the tool accurately.

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 none of the three parameters (type, limit, offset) are explained in the description. It does not clarify what 'type' values are valid or how limit and offset behave, leaving the agent without enough information to invoke the tool correctly.

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' with the resource 'suppressions' and confirms the operation with 'GET /postframe/suppressions'. It clearly identifies what the tool does, though it does not explicitly differentiate among the many sibling get/list tools beyond the resource name.

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 operational context such as 'rate limit: 100 requests per 1m' and 'Read-only', but it gives no guidance about when to use this tool versus alternatives like listCoupons, getEmails, or other list endpoints. There are no exclusions or alternative route suggestions.

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 are absent, so the description carries the full burden, and it does well: it explicitly states the call is read-only, reveals the HTTP method, and includes a concrete rate limit of 100 requests per 1m. It does not describe pagination behavior or response shape, but the safety and throttling traits are clearly disclosed and not contradicted by any 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?

The description is a single compact sentence that front-loads the core action and packs the endpoint, rate limit, and read-only safety hint into the remainder. Every word adds value 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 simple read-only list call with only two optional parameters, the description is nearly complete: it provides the endpoint, method, read-only semantics, and rate limit, and calling with no parameters is safe. It is slightly incomplete because it does not explain pagination parameter semantics or point to getTemplatesById for single-template retrieval.

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 mention limit or offset at all. While the parameter names are conventional and hint at pagination, the tool description adds no explicit meaning about their behavior, bounds, or defaults beyond what the bare schema already offers.

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 verb and resource ('List templates') plus the exact endpoint 'GET /postframe/templates', so an agent knows the tool lists multiple templates. It does not explicitly differentiate from siblings like getTemplatesById, but the plural 'templates' and the list-oriented endpoint make the scope reasonably clear.

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 alternatives. The description does not mention getTemplatesById for retrieving a single template, nor any other selection criteria such as filtering, sorting, or preferred use cases. The rate limit and read-only annotation are operational constraints, not usage 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 provided, the description carries the behavioral disclosure burden and does disclose the rate limit, read-only nature, and HTTP method. It does not mention authentication or error behavior, but for a simple GET tool this is a reasonable level of 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?

The description is one compact sentence that leads with the core operation and then adds operational constraints. There is no filler or redundancy.

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 read-only fetch tool with no output schema, this is sufficient: it names the resource, the ID, the method, the read-only behavior, and the rate limit. It omits return shape details, but those are not strongly required for such a minimal 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 schema only defines id as a string with 0% description coverage. The description adds meaning by showing that id is the template identifier in the URL path, which helps an agent populate it correctly despite the sparse 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 states a specific action, 'Get a template', and pins the resource via the endpoint GET /postframe/templates/{id}. The by-id path clearly distinguishes it from the sibling getTemplates list tool.

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 no explicit when-to-use or when-not-to-use guidance, and does not name alternatives. The required id parameter and endpoint imply this is the fetch-by-ID counterpart to getTemplates, but that distinction 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?

With no annotations, the description carries the behavioral disclosure burden. It proactively discloses the rate limit (100 requests per 1m) and the read-only nature of the request, which are the most important operational behaviors. It does not cover 404/error handling, but the disclosed rate limit and safety profile go beyond a minimal mention.

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 conveys the operation, the rate limit, and the read-only nature, with zero filler. The critical operation is front-loaded, and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter GET without an output schema, the description covers the core contract: operation, rate limit, and idempotent safety. It stops short of documenting not-found behavior or authentication requirements, but these are common assumptions for such a read-only lookup and the tool's simplicity mitigates the omission.

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, so the description must add meaning to the single 'id' parameter. 'Get transaction by ID' explicitly maps the id parameter to a transaction identifier, which clarifies its role. For a single string parameter, this is sufficient semantic grounding.

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 opens with 'Get transaction by ID', a specific verb and resource that unambiguously identifies the tool's function. It also distinguishes itself from listTransactions (which lists multiple transactions) by focusing on a single ID lookup.

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 that this is a read-only single-transaction lookup, but it does not explicitly state when to choose this over the sibling listTransactions or other listing tools. Usage is implied by the name and 'by ID' but no alternatives or exclusions 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 full burden and does well: it discloses that the operation is read-only, specifies the HTTP method, and surfaces the rate-limit constraint. It does not describe the response shape, but for a simple no-argument GET this is a minor gap.

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 compact sentence that front-loads the core action, then adds the essential rate-limit and read-only context. 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 zero-parameter, read-only quota lookup, the description provides the endpoint, method, and rate limit—enough for an agent to select and invoke the tool correctly. It does not explain the return payload, but the tool is simple enough that this does not block correct use.

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 has zero parameters and the schema is empty, so the description has no parameter semantics to add. The baseline of 4 applies because no parameter guidance is needed for correct invocation.

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 ('Get') and resource ('usage quota'), and reinforces it with the exact endpoint. This is clearly distinct from the sibling tools, which target other resources like analytics, customers, or subscriptions.

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 by identifying this as a quota/rate-limit check and explicitly noting the 100-requests-per-minute limit. It does not name alternatives, but the resource is unambiguous among the 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?

No annotations are provided, so the description carries the full burden. It explicitly discloses the HTTP method, endpoint, read-only nature, and a rate limit of 100 requests per 1 minute. This goes beyond the bare 'List webhooks' statement and gives the agent useful operational constraints, though it does not cover authorization or response shape.

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 compact statement with the core action front-loaded, followed by the two most operationally relevant details: rate limit and HTTP method/endpoint. Every word adds value and there is no redundancy.

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 zero parameters, no annotations, and no output schema, the description is sufficiently complete. It tells the agent the endpoint, method, safety profile, and rate limit, which is everything needed to select and invoke the tool correctly.

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 has zero parameters, and the schema coverage is complete, so there is no parameter ambiguity. The description need not add parameter details because none exist; this is the appropriate baseline for a no-parameter 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 clearly states a specific verb and resource: 'List webhooks'. It is distinct from sibling tools like listWebhookEvents, and the endpoint 'GET /postframe/webhooks' removes any ambiguity about the target resource.

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: whenever webhooks need to be listed. However, it does not explicitly contrast with sibling tools such as listWebhookEvents, nor does it state any conditions for choosing this tool over alternatives. The read-only and endpoint details provide context but no exclusions or alternative routing.

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 of behavioral disclosure. It explicitly labels the operation as 'Read-only', specifies 'GET /paygate/api-keys', and reveals the rate limit (100 requests per 1m). This adds important safety and operational context beyond a bare 'List API keys'. It does not disclose return format or pagination, but for a simple list operation this is reasonable.

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 compact sentence with the core action front-loaded, followed by parenthetical operational details. Every word adds value, and there is no redundancy or 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 no-parameter, read-only tool, the description covers the essential invocation details: method, path, and rate limit. However, it lacks any differentiation from the closely named sibling 'getApiKeys', and does not describe the return shape or possible pagination. The absence of an output schema makes those details more important for an agent to select the tool confidently.

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 the baseline is 4. The description adds no parameter details because none exist. The phrase 'for the tenant' clarifies the scope of the operation, which is a small contextual bonus.

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 'List', the resource 'API keys', and the scope 'for the tenant'. It also gives the HTTP method and path, making the operation unambiguous. However, it does not distinguish itself from the sibling tool 'getApiKeys', which appears to cover the same resource.

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 about when to use this tool versus alternatives. The description only restates the action, and neither mentions 'getApiKeys' nor any condition that would select one over the other. An agent must guess which API-key tool fits a given request.

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 full behavioral disclosure burden. It explicitly discloses that the operation is read-only, names the HTTP method, and states a concrete rate limit of 100 requests per minute. It does not cover pagination or default limit behavior, but the disclosed traits are meaningful and go beyond the schema.

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 front-loaded: it states purpose first, then rate limit, then read-only/HTTP method. Every clause adds useful information with no filler or 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?

For a low-complexity tool with one optional parameter, the description covers the core purpose and important behavioral constraints, so a no-argument call is reasonably supported. However, it leaves the 'limit' parameter semantics and the response shape to inference, which makes informed use of the optional parameter incomplete.

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 one parameter ('limit') with 0% description coverage, and the description does not mention it at all. The agent receives no information about what the limit controls, its default, maximum value, or units, so the description fails to compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource ('List recent Checkout sessions') and clarifies the endpoint ('GET /paygate/connect/checkout/sessions'). This clearly distinguishes it from sibling list tools focused on other resources such as listTransactions or listCustomers.

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 purpose line implies when to use it (when recent Checkout sessions are needed) and the 'Read-only' wording signals a safe retrieval operation. However, it does not explicitly contrast this tool with sibling list tools or state when not to use it, so usage guidance is only implied rather than 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?

With no annotations provided, the description carries the full behavioral burden. It discloses that the operation is read-only, specifies the GET method, states a concrete rate limit (100 requests per 1m), and clarifies scope. It does not mention pagination or return shape, but the included operational details go well beyond a minimal definition.

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 compact sentence that front-loads the action and resource, then appends the rate limit and endpoint info in parentheticals. There is no filler or redundant text; every element contributes to correct invocation.

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 list operation, the description adequately covers scope, read-only behavior, method, and rate limiting. It does not explicitly describe pagination or the exact return payload, but given the low complexity and absence of an output schema, the definition is sufficient for an agent to select and invoke the tool correctly.

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 has zero parameters, so parameter semantics are trivially satisfied. The baseline of 4 applies, and the description's scoping explanation ('on the connected account') adds useful context even though no schema parameters exist.

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, 'List', and a clear resource, 'Stripe coupons', with a scoping phrase, 'on the connected account'. This clearly distinguishes the tool from sibling list tools like listPayouts and listSubscriptions, without needing to open schemas.

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 clear context: the tool lists Stripe coupons belonging to the connected account. No sibling tool targets the same resource, so when-to-use is easily inferred. It lacks explicit exclusions or when-not-to-use guidance, but the resource specificity makes that a minor omission.

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 explicitly discloses that the tool is read-only, provides the exact endpoint, mentions the rate limit (100 requests per 1m), and notes the aggregation source from transaction history. This is valuable behavioral context beyond the raw schema.

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 core action, but the multiple parentheticals create a slightly cluttered structure. The rate limit and read-only details could be formatted more cleanly, yet there is no fluff.

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?

Although the description conveys read-only status and rate limiting, it omits parameter semantics, default pagination behavior, sort field options, and search syntax. For an agent to call this tool correctly with the provided 5 parameters, the description is insufficient.

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 across 5 parameters, and the description provides no explanation of limit, offset, search, sort_by, or sort_dir. An agent must guess at valid values, defaults, and semantics, which is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' and the resource 'customers', and clarifies the resource is 'aggregated from transaction history', which distinguishes it from sibling tools like getContacts or getCustomerByEmail. It also states the HTTP method GET, making the operation concrete.

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 does not say when to prefer this tool over alternatives or when not to use it. It provides no comparativedirection among the many sibling list/get tools, leaving the agent to infer usage from the tool name 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states read-only, includes the HTTP method, and discloses a rate limit of 100 requests per minute. However, it does not disclose response format, default/expected ordering, limit/offset semantics, or error behavior.

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-loads the core purpose. The rate limit and read-only details are parenthetical extras that add useful context without redundancy. It is economically written, though it sacrifices necessary detail for brevity.

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 list endpoint with three undocumented parameters and no output schema, the description is insufficient. It omits parameter semantics, pagination behavior, and response structure. Only rate limit and read-only are covered, leaving agents to guess at invocation details.

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 any of the three parameters: limit, offset, and status. An agent cannot determine valid status values or how limit/offset affect results. This is a critical gap because the schema itself provides no descriptions either.

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 ('List') and resource ('disputes'), clearly indicating a collection-read operation. The explicit GET path reinforces the resource and endpoint. It does not explicitly contrast with getDisputeById, but the plural resource and list verb make the purpose clear enough to distinguish.

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 no guidance on when to use this tool versus getDisputeById or other list* siblings. No prerequisites, exclusions, or pagination/filtering context are offered. The only extra context is the rate limit and read-only nature, which are not usage-selection criteria.

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 provides some behavioral context beyond the schema: it notes a rate limit (100 requests per 1m) and declares read-only status with the HTTP method (GET). However, with no annotations, it leaves out pagination behavior, sorting, or return format, which are relevant for a list endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that front-loads the core purpose. It includes useful constraints (rate limit, read-only) without fluff, though the inclusion of the raw HTTP path is slightly 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?

For a simple list operation with two optional parameters, the description is minimally adequate but omits return structure, pagination details, and any edge cases. Without an output schema, the agent lacks information about the response shape, making the tool incomplete for correct invocation.

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 defines 'limit' and 'offset' but provides no descriptions, and the description does not mention them at all. Since schema coverage is 0%, the description fails to compensate, leaving the agent without guidance on how these parameters affect the call.

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 'List' and the resource 'Stripe Connect payouts', distinguishing it from siblings like listCoupons and listTransactions. It is specific enough for an agent to identify the tool's purpose without 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 on when to use this tool versus alternatives. It doesn't mention prerequisites, typical scenarios, or how it relates to other payout-related tools (e.g., getConnectBalance). The agent must infer usage from the resource name 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only, indicates a GET endpoint, and discloses the rate limit (100 requests per 1m). This adds meaningful behavioral context beyond a simple 'list' statement.

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, information-dense sentence. It front-loads the core action and resource, then adds rate limit, read-only status, and endpoint in a compact format. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema list tool, the description is sufficiently complete. It specifies what is listed, where (connected account), the HTTP method, read-only behavior, and rate limiting. Nothing essential is missing for an agent to invoke it correctly.

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 no parameters, so schema coverage is trivially 100% and the baseline is 4. The description adds useful context by identifying the target resource ('Stripe products/plans') and scope ('connected account'), which helps the agent understand what the tool operates on even without parameters.

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 ('List') and a clear resource ('Stripe products/plans on the connected account'). It differentiates from sibling tools by naming the exact domain (Stripe products/plans) and the account scope, so an agent can distinguish it from listCoupons, listTransactions, 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 clearly conveys when to use this tool: to retrieve Stripe products/plans for the connected account. It does not explicitly exclude alternatives or name siblings, but its stated resource and scope make the use case unambiguous enough given the sibling set.

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 present, so the description carries the behavioral disclosure burden. It explicitly states 'Read-only (GET ...)' and gives a concrete rate limit of 100 requests per 1m, which is useful operational context beyond the name.

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 front-loaded sentence that states the action first, then adds rate-limit and read-only details. Every phrase earns its place, with no filler or unnecessary elaboration.

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 list tool, the description covers purpose, HTTP method, read-only behavior, and rate limiting. It does not describe the response shape or pagination, but the simple list action and lack of parameters make this gap minor.

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 has zero parameters and schema coverage is 100%, so there is nothing meaningful for the description to add. Parameter semantics are effectively complete by virtue of the parameterless input 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 states a specific action ('List') and a specific resource ('configured payment providers'), making the tool's purpose clear. However, it does not differentiate listProviders from its sibling getProviders, so it misses the top score.

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 no explicit guidance about when to use this tool versus alternatives such as getProviders. The 'Read-only' and rate-limit details imply a safe listing operation, but there are no when-to-use or when-not-to-use instructions.

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 discloses useful behavioral traits: the operation is read-only, uses GET, and is rate-limited to 100 requests per minute. It does not cover pagination or return format, but this is minor for a parameterless list endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one compact sentence with the core purpose front-loaded and rate-limit/read-only constraints appended efficiently. 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?

For a simple zero-parameter GET endpoint, the description provides the key invocation details: resource, HTTP method, rate limit, and safety profile. It lacks explicit alternatives or return-value expectations, but those are not essential for calling this tool correctly.

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 has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details because no parameters exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('List'), a specific resource ('routing rules'), and the HTTP endpoint. This clearly distinguishes it from the many sibling list tools, none of which mention routing.

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 about when to use this tool versus alternatives. The rate limit and read-only note are operational constraints, not usage context or exclusion criteria.

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 full burden and discloses meaningful behavioral traits: the operation is read-only, uses GET, and is rate-limited to 100 requests per minute. This is valuable safety and throttling context that the schema alone would not convey, though it omits details like pagination or empty-result behavior.

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 short clauses in one sentence, each earning its place: the purpose+scope, the rate limit, and the read-only/GET disclosure. Nothing is wasted and the most important verb-resource info is front-loaded.

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 list tool with 2 optional params and no output schema, the description covers purpose, scoping, safety, and throttling. The notable omission is parameter semantics, which keeps it from being fully complete, but the overall complexity is low and the core call path (GET subscriptions on connected account) is fully specified.

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 'search' and 'status' having no meaning anywhere. It does not explain what 'status' filters by or what 'search' searches across. Two filter parameters are left completely undocumented, which is a real gap for an agent deciding what to pass.

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 ('List'), a clear resource ('Stripe subscriptions'), and a scope ('on the connected account'), plus the HTTP endpoint. This unambiguously distinguishes it from siblings like listCoupons or getBillingSubscription without requiring schema inspection.

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 core usage context is clear: use this to list subscriptions scoped to the connected account. It does not explicitly name alternatives (e.g., getBillingSubscription for a single subscription) or state when-not-to-use, but for a simple list tool the intended scenario is evident and no competing tool is misrouted by this 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?

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly discloses that the operation is read-only and states the rate limit (100 requests per 1m), which is valuable. However, it does not mention pagination behavior, default limits, response shape, or whether results are ordered.

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 compact sentence that leads with the core purpose and includes useful constraints (rate limit, read-only, HTTP method). It is not verbose, though it sacrifices substance for brevity in parameter guidance.

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 list tool with eight optional parameters and no output schema, this description is incomplete. The read-only and rate-limit details help, but the absence of parameter semantics, pagination defaults, and any sense of the response structure means an agent cannot reliably invoke it beyond a bare request.

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 any of the eight parameters. The agent is left without any information about type, format, status, provider, search, from_date, to_date, limit, or offset, so it cannot build meaningful requests.

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 exact action and resource ('List transactions') and reinforces it with the HTTP endpoint 'GET /paygate/transactions'. It is clearly distinguished from the sibling getTransactionById because one is a list operation and the other is a single-record lookup.

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 instead of alternatives like getTransactionById, listPayouts, or listCheckoutSessions. The only implied usage is 'list transactions', but there are no explicit conditions, exclusions, or 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 burden of behavioral disclosure. It explicitly states 'Read-only (GET)' and the rate limit of 100 requests per 1m, providing safety and throttling context. It does not mention pagination or auth, but the core behavioral traits are disclosed.

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, focused sentence that front-loads the action, then provides the rate limit and endpoint. Every clause adds value, with no filler or redundancy.

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 core purpose, read-only semantics, and rate limiting, which is enough for basic understanding. However, with no output schema and no parameter documentation, an agent cannot fully determine valid status or event_type values without external guesswork.

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 mention any of the four parameters. 'limit' and 'offset' are somewhat self-evident, but 'status' and 'event_type' have no documented allowed values or meaning, leaving a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List webhook delivery events.' It adds the HTTP method and endpoint path, which makes the tool's role unmistakable and distinguishes it from sibling tools like getWebhooks or listTransactions.

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 states what the tool lists and that it is read-only, but it does not explicitly say when to choose this tool over sibling tools or when not to use it. Usage is implied by the resource name rather than explicitly contrasted with alternatives.

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