Kourier

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

Annotations already declare non-readonly, non-idempotent, open-world behavior, and the description reinforces this with exactly-once semantics, a no-retry rule after ambiguous delivery, and secrecy handling for the returned key ('keep the key private', configure client only with user approval). The ambiguous-delivery warning is real behavioral guidance that annotations cannot express.

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 sentences, well front-loaded: the action first, then the no-retry rule and status alternative, then the privacy handling. Every sentence carries instruction, with only minor redundancy between the retry rule and the private-key note.

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, non-idempotent mutation with no output schema, the description covers preconditions, the exactly-once contract, retry behavior, and what is delivered. Nothing an agent needs to invoke it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single required parameter, and the schema already states 'Private onboarding token. Never show it to the human or log it.' The description adds no further syntax or format detail about the token, so the baseline 3 applies.

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

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

States a specific action (deliver a dedicated revocable inference key) scoped to 'exactly once after human approval and active entitlement', which is a concrete verb+resource. It also implicitly distinguishes itself from get_onboarding_status by telling the caller to 'check status instead'. Slightly abstract phrasing ('inference key') keeps it from a full 5, but an agent can tell what this does.

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?

Explicit precondition (human approval plus active entitlement) and an explicit failure/alternative route: 'Never retry after issuance or ambiguous delivery; check status instead.' That names the condition and routes to the correct sibling instead of blind retries.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false; the description adds real context on top: it does not charge or issue a key, the token must be kept private, and only onboarding_url and user_code should be shown to the human. That is meaningful operational and safety context beyond the structured hints, though auth requirements and link expiry/lifetime are not 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?

Three sentences, roughly 40 words, with the core action front-loaded and no filler. The opening sentence is a heavy noun pile ('verified sign-in, recurring Starter/Pro plan and explicit agent access approval link') that costs a little readability but nothing is 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?

There is no output schema, and the description usefully names the returned fields (onboarding_url, user_code, token) and their disclosure rules, which an agent would otherwise have to discover at runtime. Combined with the no-charge/no-key boundary, this is close to complete for a non-idempotent, open-world link-creation tool; only follow-up flow and auth preconditions are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%: harness and client_name are documented in the schema, while plan is only an enum. The description reinforces the plan parameter ('Starter/Pro plan') and frames client_name as the human-readable name, but adds no new meaning for harness or client_name beyond what the schema already states, so the baseline 3 applies.

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

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

The description gives a specific verb (Create) and a scoped resource: an approval link tied to a verified sign-in and a recurring Starter/Pro plan. It is clear enough to distinguish from read-style siblings like get_onboarding_status or get_setup_instructions, though it never names an alternative and the compound object ('sign-in, ... plan and ... link') makes it slightly unclear whether one artifact or several are produced.

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

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

Usage is only implied via the title ('Start ... onboarding') and the boundary sentence 'This does not itself charge or issue a key,' which hints this is a first step that must be followed by another call. There is no explicit when-to-use, when-not, or reference to sibling tools such as complete_onboarding or get_onboarding_status.

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 already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds real value by disclosing what the payload contains (three distinct acquisition methods, including an agent sign-in path and PKCE flow), but says nothing about whether the output is static reference text or account-specific, nor about 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?

A single dense sentence, front-loaded with the core purpose and then the enumerated content. No filler, though the 'How a person or an agent obtains...' framing is slightly indirect compared to a leading verb like 'Returns instructions for...'.

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, no-output-schema lookup tool with annotations already covering safety, the description tells the agent everything needed to decide to call it: the resource and the three paths covered. The remaining gap is that an agent cannot tell from the description how this differs in scope from get_setup_instructions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case: there is nothing for the description to disambiguate. The absence of inputs is consistent with a pure documentation-retrieval 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 the concrete resource (a Kourier API key) and the exact content returned (three acquisition paths: dashboard sign-up, agent sign-in via auth.md, OAuth with PKCE). It is clearly about getting instructions rather than performing onboarding or setup, though it never explicitly distinguishes itself from the sibling get_setup_instructions.

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

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

Usage is only implied: an agent can infer it should call this when it needs to acquire an API key, and the mention of auth.md and OAuth hints at the agent-facing paths. There is no explicit when-to-use or when-not-to-use guidance versus get_setup_instructions or complete_onboarding, which an agent could easily confuse with this 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context of its own — no caching, auth, or freshness notes — it only restates the payload contents, so it contributes little beyond the annotations.

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

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

A single sentence fragment with no filler; the most important content (the served model and its limits) is front-loaded. It is on the terse side, but nothing is wasted and nothing essential is buried.

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

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

With no parameters and no output schema, the description usefully enumerates the three things returned, which is the main gap a caller would otherwise face. It omits return structure and cardinality, but for a trivial read-only lookup this is close to 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 tool takes zero parameters, so the baseline is 4. The description does not need to explain any inputs, and it adds the useful detail of what the response payload contains (model string, context limits) rather than leaving it entirely opaque.

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 specific resource it returns — the served model, its API model string, and context limits — which is enough for an agent to know exactly what data comes back. It is a noun-phrase summary rather than an explicit verb+resource statement, and it does not contrast itself with any sibling, but the purpose is unambiguous.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The sibling list (pricing, setup, onboarding, checkout) does not obviously overlap, but the description gives the agent nothing to reason about regarding when this call is appropriate.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds real value on top: it discloses the polling contract, the absence of identity/secret requirements, and the terminal states. It does not say what a pending/in-progress state looks like, but the added context is substantial.

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 sentences, front-loaded with the purpose before the polling mechanics. Efficient overall, though the first sentence is dense with undefined jargon ('signed-webhook-backed entitlement') that costs a little parsing effort.

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 tool with no output schema, the description usefully compensates by enumerating the terminal states (issued, denied, expired) that end polling. What remains missing is the pending/in-progress value and where the returned entitlement actually lives, but coverage is strong for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single onboarding_token is fully documented as private and never to be logged, so the schema does the heavy lifting. The description's 'without identity or secrets' hints at the token's confidentiality but adds no syntax or handling detail beyond the schema.

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

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

States a specific verb (Check) and resource (approval and entitlement), and the 'without identity or secrets' clause scopes what the check requires. However, it never names the sibling it differs from (e.g. complete_onboarding), and 'signed-webhook-backed entitlement' is jargon an agent must interpret.

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?

Gives concrete operational guidance: poll every 5 seconds, complete only when ready, stop on issued/denied/expired. This tells the agent how to drive the loop, but it does not name the alternative tool to call once the state is ready, leaving the handoff to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful content context (concurrency limits and what is uncapped) but says nothing about output format, freshness, or whether pricing is a static snapshot.

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

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

A single front-loaded sentence with no filler; every listed item is informative. It reads as a terse noun phrase rather than a full sentence, which is slightly clipped but not wasteful.

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 information tool with no output schema, the description covers the substance an agent needs to decide whether to call it. Only minor gaps remain, such as output shape and data freshness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate.

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 enumerates exactly what the tool surfaces: plans, monthly prices, concurrency limits, and uncapped resources. That is specific enough to distinguish it from siblings like get_models or get_onboarding_status, though it is phrased as a content list rather than a verb+resource statement.

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

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

There is no explicit when-to-use or when-not-to-use guidance, but the content listing makes the use case (answering pricing/limit questions) self-evident, and no sibling competes for the same intent. Usage is implied rather than 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?

Annotations already cover readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety behavior is fully declared. The description adds essentially nothing beyond the client list, which the enum already provides, and says nothing about what is returned or whether it requires an existing account/API key.

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

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

A single tight sentence with no filler, though it is arguably under-specified rather than concise. It is front-loaded with the resource topic.

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 read-only, single-parameter tool with complete schema coverage, the description is close to adequate, but with no output schema it should clarify what 'configuration' resolves to (a config snippet, command, or link) and how it relates to the API-key instructions sibling. Those gaps leave the agent guessing at the return.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single, well-documented enum parameter, so the schema carries the semantic load. The description naming the four client types loosely mirrors the enum but adds no format or behavior detail, making the baseline 3 appropriate.

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

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

The description is a noun phrase ('Configuration for using Kourier...') that conveys the topic but never states the action the tool performs, unlike the verb-fronted sibling names get_api_key_instructions and get_models. It enumerates the supported clients, which helps, but gives no signal distinguishing it from the closely related get_api_key_instructions sibling.

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

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

There is no guidance on when to call this versus the sibling get_api_key_instructions or get_models, and no prerequisites or sequencing advice. The only hint ('Omit for the generic OpenAI-compatible settings') lives in the schema, not the 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?

Annotations declare it is a non-read-only, non-destructive, non-idempotent call, and the description adds genuinely non-structured context: authentication must arrive via the MCP connection's Authorization: Bearer header, never in arguments, and the submission is attributed to the caller's account. It omits rate limits and what happens to a submitted report after delivery, keeping it short of a 5.

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

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

Four short sentences, front-loaded with purpose before the auth and data-hygiene rules. Efficient overall, though the secrets-exclusion sentence partially duplicates the message parameter's schema description.

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 small non-destructive submission tool with no output schema, the description covers purpose, auth mechanics, attribution, content hygiene, and optional request_id correlation. Only the post-submission behavior (any acknowledgement or tracking) is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, and the schema already documents message, request_id, and the kind enum. The description only echoes this guidance (include request_id when available; no secrets in the message) without adding new semantics such as expected request_id format or how kind affects downstream handling.

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+resource pair ('Send feedback or report a Kourier error') and immediately adds the attribution model ('attributed to your account'). This is unmistakably distinct from every sibling tool (onboarding, checkout links, models, pricing, setup instructions), so an agent can route to it without opening 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?

Gives clear usage context: submit what the user wants to share, exclude secrets/personal data, and include a request_id when available. It does not explicitly contrast 'feedback' vs 'error' selection even though the kind enum splits them, and names no alternative tools — but no sibling overlaps this purpose.

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