Boat House

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the returned data fields and the authorized audience, and it implies a non-mutating listing operation, but it does not explicitly state that no mutation occurs, whether the list is scoped to the current workspace, or how empty results behave.

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 no filler and includes several concrete data points. It is slightly less scannable because it begins with a noun phrase ('Everyone waiting...') rather than an imperative verb, but it is still appropriately brief.

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 listing tool with one optional parameter and no output schema, the description conveys what the tool shows, which fields are present, and who is allowed to see it. It does not explicitly state that this is a read-only list or describe edge cases, but the essential invocation information is present.

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 100% description coverage for the only parameter, workspace, so the schema already explains its meaning. The description adds no additional parameter semantics, placing this at the baseline 3.

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

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

The description identifies the resource as people waiting to be granted access to workspace tools and enumerates the included fields: request id, email, tier asked for, and message. It clearly differs from action-oriented siblings like request_access and allow_request, though it never uses an explicit verb such as 'list' or 'get'.

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?

It provides useful context by indicating the tool shows pending requests and restricts visibility to owners and tool admins. However, it gives no explicit guidance about when to use this tool instead of allow_request, request_access, set_access, or other access-related siblings, and no when-not conditions.

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 the side effects: the grant is made and an email is sent. It does not mention reversibility, permission requirements beyond 'Owners and tool admins', or what happens if the request is already processed. With no annotations, this is adequate but not rich.

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, each adding distinct information: the action, the effects, and the audience. 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 two-parameter action with no output schema, the description covers the core behavior and the actor. It could mention error cases or idempotency, but the essentials are present.

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 100%, so the schema already documents both parameters. The description adds no extra meaning about the id or workspace beyond what the schema provides, 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 clearly states the action ('Let a waiting person in'), the resource ('at the tier they asked for'), and the immediate effects (tool grant made, email sent). It also names the intended audience ('Owners and tool admins'), which distinguishes it from request_access and access_requests.

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 the context: use this when someone is waiting for access and you are an owner/admin. It does not explicitly say when not to use it or name alternatives like set_access, but the sibling context and the phrase 'waiting person' make the usage clear.

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 at all, the description carries the full burden of behavioral disclosure. It implies a read-only workspace status snapshot by listing informational fields, but it never explicitly says the operation is non-mutating, idempotent, or returns a status report. No side-effect or safety information is provided.

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 resource and then efficiently enumerates the relevant data categories. It is not bloated, though it could be strengthened by leading with an action verb.

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 read tool with one optional parameter, the description covers the main returned content areas well. However, with no output schema and no annotations, it does not clarify return format, authentication expectations, or definitive read-only semantics, leaving a moderate 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 single optional workspace parameter is fully covered by the schema description, so the baseline is 3. The tool description does not add any extra meaning about the parameter, but given 100% schema coverage, no compensation is required.

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

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

The description clearly identifies the resource as workspace billing and lists the exact data categories it exposes (balance, pause state, burn rate, days left, card on file, ledger lines). It lacks an explicit verb like 'gets' or 'returns,' and does not directly contrast with sibling tools, so it stops short of a 5.

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

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

There is no guidance on when to call billing versus siblings like topup, card_link, or usage. The description lists content but never tells an agent when this tool is the right choice, when to avoid it, or what to use instead.

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

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

With no annotations, the description carries the full burden and does substantive work: it discloses the two-phase quote/approve flow, explicitly states "No automatic upgrade", and restricts use to owners. It does not describe return values or side effects, but the core behavioral traits are present.

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 four short sentences with no filler. Each sentence contributes either the resource, the workflow, the safety guardrail, or the permission requirement.

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 tool with no output schema and no annotations, the description covers the main quote-and-approve flow and the owner gate. It lacks explicit sibling alternatives and a clear statement of what the tool returns, but it is otherwise sufficient 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 100%, so the schema already documents all six parameters. The description adds workflow context around approval and confirmation, but no per-parameter specifics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

"Quote additional app storage" is a specific verb and resource, and "No automatic upgrade" plus "Owners only" help distinguish it from billing or top-up tools. However, no sibling tool is named, so the agent must infer when capacity is the right choice rather than prices, billing, or topup.

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 eligibility and workflow context ("Owners only", "get owner approval before confirming") but never states when to use this tool versus alternatives like billing, prices, or topup. There is no when-not-to-use guidance or explicit 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 behavioral burden and discloses the one-time nature, browser requirement, and owner restriction. It does not state return behavior or expiry beyond 'one-time', so it is not 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?

Two short sentences, front-loaded with the core action, no filler or redundant detail.

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

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

For a low-complexity one-parameter tool, the description provides purpose, auth, and a distinguishing constraint. It lacks an explicit return/output statement, but that is largely implied by 'one-time link' and no output schema exists.

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

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

The single optional workspace parameter is fully documented in the schema, and the description adds no further parameter nuance beyond the owner context. 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 the deliverable (one-time link), the action (owner enters a card into Stripe), and a unique distinguishing trait (browser-required). This separates it from billing/topup/prices siblings without needing their 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?

Clearly signals the use case (one-time card entry) and restricts callers to workspace owners, but does not explicitly name sibling alternatives or state 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 full burden, and it does well: it states that database/files are kept by default, that purge destroys them forever, and that purge_confirm is then required. It could additionally state whether the default container/release/sharing deletion is itself irreversible, but the core destructive behavior is clearly 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?

Two compact sentences, front-loaded with the primary action, and every clause adds information: scope of deletion, default retention, purge behavior, and confirmation requirement. 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 destructive tool with no annotations and no output schema, the description covers the main effects, defaults, and conditional requirement. Minor gaps remain, such as whether the non-purge deletion is reversible and how workspace selection interacts with the tool short name, but the schema covers the workspace parameter and the core invocation path is clear.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the default behavior of purge ('By default the tool's database and files are kept') and by reinforcing the purge/purge_confirm dependency. This helps the agent understand the conditional relationship without opening 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 ('Delete') and resource ('tool'), then enumerates exactly what gets removed: container, releases, and sharing. This distinguishes it from read-only siblings like get_tool and list_tools, and from partial operations like share, unshare, and releases.

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 delete_tool versus alternatives, and no exclusions or prerequisites. Since this is a destructive operation among many non-destructive sibling tools, the agent gets no help deciding whether to inspect first with get_tool or 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 full burden of behavioral disclosure. It explains that the first deploy creates the tool and later deploys replace the running container, requires a Dockerfile listening on $PORT, and mentions the STALE_BASE refusal for stale base values. It does not mention permissions or atomicity, but the central mutation behavior is explicit.

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 dense sentences with no filler. The action and outcome are front-loaded, followed by the critical file contract, then the versioning safeguard. Every sentence earns its place.

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

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

Given there is no output schema and no annotations, the description covers the essential lifecycle, file requirements, and the stale-base failure mode. It does not state what a successful response contains or enumerate other validation failures, but an agent has enough to invoke the tool correctly and interpret its key risk.

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 covers all parameters, so the baseline is 3 distributed. The description adds valuable semantics beyond the schema: files must include a top-level Dockerfile listening on $PORT, and base should be the release number from pull to prevent silent overwrites. These constraints are not fully expressed in the parameter descriptions alone.

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: deploy a folder as a tool and make it live at a URL. It clearly distinguishes creation on first deploy from replacement on subsequent deploys, differentiating it from sibling operations like get_tool, list_tools, rollback, or restart.

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 context: use this tool to make a folder live as a tool. It adds a specific when-condition around the base parameter, warning to pass the pulled release number to avoid silently overwriting a concurrent deploy, but it does not explicitly exclude alternatives like rollback or restart.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does a solid job: it states that Boathouse starts answering on the domain, that DNS records are returned, that the operation is owner-only, and that the tool can optionally be pointed at one tool simultaneously. It doesn't discuss reversibility or DNS propagation, but the core behavioral consequences 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 two sentences with no filler. It front-loads the action and immediate consequence, then mentions the optional tool behavior and access restriction. Every sentence earns its place.

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

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

For a three-parameter tool with no output schema, this description is largely complete: it conveys when it applies, what changes, what is returned, and who can invoke it. It doesn't cover failure modes or how to undo the attach, but an agent has enough to call it correctly in the basic case.

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%, so the baseline is 3. The description adds only light reinforcement for the 'tool' parameter ('point it at one tool') and nothing new about 'domain' or 'workspace' beyond what the schema already documents. Since every parameter is already well-described in the schema, no compensation is required.

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 ('Bring a domain the workspace already owns elsewhere'), the system affected ('Boathouse starts answering on it'), and the result (DNS records returned). The 'already owns elsewhere' clause distinguishes it from buying or checking domains, but it does not explicitly differentiate it from nearby siblings like domain_point or domain_repoint, so it falls just short of a 5.

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

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

The description implies the intended use case—attaching a domain the workspace already owns elsewhere—and mentions an optional tool association. However, it provides no explicit when-to-use vs. when-not-to-use guidance and no named alternatives among the many domain-related sibling tools, so the agent must infer the right 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?

With no annotations, the description carries the full burden of disclosure, and it does so well. It reveals the dry-run/confirm behavior, the contents of the quote (cost, renewal, balance), the payment source, and the owner-only restriction, making the side effects of the tool clear before invocation.

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

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

Two sentences, front-loaded with the core purpose, followed by the essential safety caveat about confirm. Every clause earns its place, with no redundant or generic 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 domain-purchase tool with five parameters and no output schema, the description covers the high-stakes aspects: payment source, quote-only behavior, confirmation gate, and permission. The remaining fields are fully documented in the schema, so an agent has enough to call it correctly and safely.

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 100% and the schema descriptions already explain confirm, quote_id, and max_cost_cents in detail, including 'Required to confirm.' The description adds useful context about the quote flow and prepaid balance, but the schema is doing the heavy lifting, so a baseline 3 is appropriate.

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

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

The description clearly states the action: 'Buy a domain through Boathouse's registrar and point it at this box, paid from the workspace's prepaid balance.' It names a specific verb, resource, and consequence, and the mention of buying versus pointing/checking distinguishes it from domain_check, domain_point, and domain_attach 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?

It gives concrete operating guidance: without confirm it only returns a quote and buys nothing, and it notes an 'Owners only' permission restriction. It does not explicitly name alternatives such as domain_check for availability checks or domain_point for already-owned domains, so it stops short of full exclusionary 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 full burden of behavioral disclosure. It explicitly states the tool has no purchase side effect and clarifies how pricing fields relate, including that total_cents is the price the workspace pays. This is strong behavioral context for a read-only check 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 with no wasted words. It front-loads the core purpose, then adds the key side-effect disclosure and the output display instruction.

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, so the description must explain return semantics, and it does by explaining total_cents, registrar_cents, and margin_cents. It does not cover error cases or what happens when a domain is unavailable, but for a simple check tool the description is 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?

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description does not add much parameter-level detail, but it references the domain being checked and the price fields, which is acceptable given full schema coverage.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Ask the registrar whether a domain is free and what it costs per year.' It also distinguishes itself from purchase-related tools with 'Buys nothing,' making its purpose 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?

The description gives clear context for when to use this tool and explicitly says it 'Buys nothing,' which tells the agent not to use it for purchasing. It does not name sibling alternatives like domain_buy explicitly, but the intent is clear enough.

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 that registration is untouched, that the action is reversible via domain_attach, and that only owners can perform it. These are key behavioral traits. It does not mention side effects like DNS or traffic, but for a 'stop serving' action 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?

Two sentences with no redundancy. The action is stated first, followed by essential caveats (registration untouched, reversibility, ownership requirement). Every clause adds 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?

For a simple 2-parameter tool with no output schema, the description covers the core semantics, reversibility, and permission requirements. It does not mention error cases or response format, but those are not critical for this action. The description is sufficiently complete for an agent to use 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?

Schema coverage is 100%, with both parameters fully described in the schema. The description adds no additional parameter information beyond what the schema provides. Baseline of 3 is appropriate when schema covers all 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 clearly states the action ('Stop serving a domain'), identifies the resource, and distinguishes it from domain_attach by noting the operation is reversible. It also adds a permission constraint ('Owners only'), making the purpose unambiguous and differentiated from sibling 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 gives context about reversibility (domain_attach brings it back) and implies when to use this tool (when you want to stop serving but keep registration). It does not explicitly mention alternative tools or when not to use it, but the context is clear enough for a simple operation.

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 'Changes nothing,' which clearly signals a read-only operation and prevents an agent from expecting mutation. It also adds the nuance that the records are the registrar's current holdings. It does not discuss permissions or failure modes, but for a simple read-only lookup this is solid 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?

Two short sentences deliver the object, scope, and side-effect profile with zero filler. The key information is front-loaded, and the explicit 'Changes nothing' earns its place as a crucial behavioral clarification.

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

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

For a simple two-parameter read-only tool with no output schema, the description is mostly complete: it states what data is returned, the domain scope, and that no changes are made. It does not describe the return format, but 'DNS records' is sufficiently informative for an agent to know what to expect, and the schema covers the parameters.

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 both `domain` and `workspace` already described meaningfully. The description does not need to add much, and it provides only general context about domains Boathouse bought or manages rather than new parameter-level syntax or constraints. This matches the baseline expected when the schema already documents all 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 clearly identifies the resource (DNS records held by the registrar) and the scope (domains Boathouse bought or manages), and even states the operation's side-effect profile with 'Changes nothing.' It distinguishes itself from domain_* siblings like domain_buy or domain_repoint by focusing on current registrar-held DNS records rather than actions on domains.

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

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

The description implies when to use the tool: when you need the DNS records currently held by the registrar for a Boathouse-owned or managed domain. However, it does not explicitly contrast with sibling tools or state when not to use it, so the guidance remains implicit rather than directive.

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 disclosing behavior. It mentions the owner-only restriction and the clearing effect of an empty tool, which are useful. However, it does not disclose potential side effects (e.g., whether it affects existing mappings), reversibility, error conditions, or what happens to the www domain if already configured.

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 exceptionally concise: three short sentences that front-load the core purpose, then add the clearing behavior and the owner restriction. Every sentence earns its place 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?

The description adequately explains the tool's function, the special empty-tool behavior, and the owner restriction. However, it omits practical prerequisites such as whether the domain must already be attached to the workspace, whether the tool must be a valid installed tool, and what happens after invocation (e.g., confirmation or error). These gaps could leave an agent unsure about correct usage.

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%, so the schema already documents each parameter. The description adds minimal extra semantics: 'An empty tool clears it' reinforces the schema's 'empty string to show the tool list again' but doesn't clarify domain or workspace parameters further. This matches the baseline for full schema coverage.

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

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

The description clearly states a specific verb ('Make') and resource ('a domain'), and specifies the behavior: the domain opens one tool instead of the workspace's tool list. It also distinguishes itself from domain-management siblings by focusing on the tool-list redirect, making its unique purpose evident even without naming alternatives.

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

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

The description gives no guidance on when to use this tool versus siblings like domain_attach or domain_primary. It only mentions an 'Owners only' permission and that an empty tool clears the setting, neither of which helps an agent decide between alternatives or identify prerequisites.

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

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

With no annotations, the description must carry the behavioral burden. It discloses the ownership requirement and the downstream impact on URLs and emails, but it does not mention side effects on the previous primary domain, prerequisites like domain being attached, or whether the operation is reversible.

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 action and consequence, then adds the ownership restriction. Every clause earns its place, with no filler or redundant restating of the tool name.

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

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

For a simple two-parameter mutation with a fully covered schema, the description supplies the key missing context: the access restriction, the domain's role, and the practical effect. It could add a note about prerequisites or previous-primary behavior, but the agent has enough 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?

Schema description coverage is 100%, with the schema already defining 'domain' as 'A domain the workspace answers on' and 'workspace' with usage context. The description adds no further parameter-level meaning, 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 uses a specific verb and resource ('Make one of the workspace's domains the primary one') and explains the practical effect (URLs and emails use it). It clearly distinguishes this from domain_attach/domain_detach, but it doesn't explicitly name or contrast an alternative sibling like domain_repoint.

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 'Owners only' gives an important authorization constraint, and the effect on URLs/emails implies when the tool matters. However, it does not explicitly state when to prefer this over sibling tools such as domain_attach or domain_point, nor does it give any '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?

Without annotations, the description carries the burden of behavioral disclosure. It states 'Read' implying a non-mutating operation, and 'Owners only' indicates access control. However, it does not elaborate on permission errors, side effects (though likely none), or the return structure. The 'Owners only' clause adds context but could be more explicit about consequences of unauthorized access.

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 with no filler. The core action and data scope are front-loaded in the first sentence, and the access restriction is stated in the second. 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 simple read tool with one optional parameter and no output schema, the description lists the types of data returned (expiry dates, renewal status, spending limits, billing problems) but does not explain the output format or whether it applies to all domains in the workspace. This is adequate but leaves minor gaps about expected results.

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 the workspace parameter with 100% coverage, so the schema already provides meaning. The description adds no additional semantics about how the parameter affects results (e.g., scoping to a specific workspace or listing all domains). This matches the baseline of 3 for high schema coverage.

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

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

The description clearly states the action ('Read') and the resource (domain expiry dates, renewal status, spending limits, billing problems). It distinguishes itself from sibling tools like domain_renewal_set (which implies mutation) and domain_buy by focusing on reading renewal-related data. However, it doesn't explicitly name an alternative, so it's 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?

No guidance is given on when to use this tool versus alternatives such as domain_renewal_set or domains_list. The description implies it is for reading, but it doesn't explicitly state the condition for using it (e.g., 'when you need to check renewal status') or exclude other tools. This leaves the agent to infer usage from the verb 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?

No annotations are provided, so the description carries the full burden. It discloses the two-phase confirm behavior (quote first, then confirm true), the consequence of disabling renewal (domain expiration), and the owner-only restriction. It doesn't mention whether the operation is reversible or what the quote contains, but the critical 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?

Three sentences with no filler. The most important behavioral constraint (quote first, confirm true) is front-loaded, and the risk warning ('Turning renewal off lets the domain expire') is included 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 mutation tool with no annotations and no output schema, the description covers the key operational context: the confirm flow, the risk of disabling, and the owner-only restriction. It doesn't describe the quote format or what happens after confirmation, but the essential information for calling the tool correctly is present.

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%, so the schema already documents all five parameters. The description adds context for enabled (false lets the domain expire) and confirm (quote first, then explicit approval), which reinforces the schema. However, it doesn't add much beyond the schema's own parameter descriptions, so a baseline 3 is appropriate.

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

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

The description states a specific verb ('Set') and resource ('automatic renewal and a maximum prepaid renewal charge'), and clearly distinguishes this from sibling tools like domain_renewals (which likely lists renewals) and domain_buy/domain_attach. The scope is unambiguous: it configures renewal behavior, not performs a renewal.

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 explicit usage guidance: quote the change first, require explicit approval with confirm true, and notes that turning renewal off lets the domain expire. It also states 'Owners only,' which is a clear access constraint. This is strong when-to-use and 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 carries the burden of behavioral disclosure. It does reveal an important requirement (owners only) and indicates the mutating nature of the operation by saying 'rewrite.' However, it does not explain potential side effects, whether existing custom DNS records are overwritten, or what happens after the rewrite.

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 leads with the action and outcome, then adds the two relevant trigger scenarios and the permission requirement. Every phrase earns its place 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 simple two-parameter tool with no output schema, the description covers what the tool does, when to use it, and who can use it. It is slightly incomplete because it does not clarify how the rewrite interacts with existing DNS records, but overall the essential guidance is present.

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 100%, so both parameters are already documented in the input schema. The description adds no additional meaning about the domain or workspace parameters beyond what the schema provides, so the baseline score 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 names a specific action (rewriting DNS records), a specific resource (Boathouse-managed domains), and the intended outcome (pointing at Boathouse again). It does not explicitly contrast itself with sibling tools like domain_point or domain_dns, but the context 'after a move, or if someone changed them' makes the purpose distinct enough.

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 usage context: use this when a domain has moved or had its DNS records changed externally. It does not explicitly mention alternatives or when not to use it, but the trigger scenarios are concrete and usable.

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

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

With no annotations, the description carries the behavioral burden. It discloses the list contents and implies a read-only listing operation, but it does not explicitly state that the tool has no side effects, nor does it clarify what DNS state values are returned. This is adequate for a simple list tool but leaves some behavior implicit.

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, tightly worded sentence with no filler. The colon structure efficiently enumerates the return contents, though starting with an explicit verb like 'List' would make it slightly more direct.

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 straightforward list operation with one optional parameter, the description covers the returned content well. However, without annotations or an output schema, it leaves the DNS-state format and the exact scoping behavior to the schema, and it gives no context about when to use this instead of the other domain 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 schema covers 100% of the one parameter, workspace, with a clear description. The tool description adds no additional parameter-level meaning beyond 'this workspace,' so the baseline of 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 identifies the resource (the workspace's domains) and enumerates exactly what is included: the free boathousecloud.com address, the primary domain, and custom domains with DNS state. This distinguishes it from sibling domain tools like domain_attach, domain_dns, and domain_point. The listing intent is implicit rather than stated with an explicit verb, but the noun-phrase description is specific and 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?

No guidance is provided on when to use this tool versus the many domain-related siblings. It does not state that this is the read-only inspection counterpart to domain_attach, domain_detach, or domain_primary, nor does it mention when a user should prefer those tools instead.

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 does state the output contents (URL, container state, current release, visibility, shared list), which indicates a read-only operation, but it does not explicitly confirm that it makes no changes, nor does it mention any permissions, rate limits, or error conditions. The description is informative but leaves safety and side-effect assumptions to the agent.

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

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

The description is a single, concise sentence that front-loads the purpose and lists the key output fields. It contains no filler or redundancy, making it efficient 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 tool's simplicity (2 parameters, no output schema, no annotations), the description covers the purpose and output fields, but lacks usage guidance and explicit read-only confirmation. It does not mention how to handle cases like a missing tool or workspace ambiguity. While adequate for a basic get operation, it leaves some gaps in context that an agent might need.

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 provides 100% coverage for both parameters (tool and workspace) with descriptions. The tool description adds no additional meaning beyond what the schema already states; it does not clarify parameter formats, default behaviors, or relationships between them. Since the schema fully documents the parameters, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: it provides details of a single tool, specifically URL, container state, current release, visibility, and shared-with list. This distinguishes it from list_tools (which lists tools) and delete_tool (which removes tools). The verb 'get' is implied by the name and the description specifies the resource and the exact fields returned.

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 this tool: when you need detailed information about a specific tool. However, it does not explicitly mention alternatives or exclusion criteria, such as 'use list_tools to see all tools' or 'do not use this for deployment'. The sibling list suggests the context, but no explicit 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?

With no annotations, the description carries the burden of behavioral disclosure. It names returned fields (state, release, URL, visibility) and defines 'tool', giving useful context. It does not state that this is read-only, describe errors, or address pagination/ordering, leaving some ambiguity.

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

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

Two tight sentences with the core result front-loaded and a useful domain definition for 'tool'. 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 list operation with an optional parameter and no output schema, the description covers the main return fields and scope. It could mention pagination or whether the list only includes tools visible to the caller, but these are minor gaps for this 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 workspace parameter is well explained in the schema (when to use it, how to discover workspace slugs). The tool description itself adds no parameter detail, 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 clearly identifies the resource (tools) and the scope (every tool in the workspace) with expected fields. It is easy to tell apart from get_tool, but it does not explicitly name or contrast sibling tools, so it stops short of full differentiation.

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

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

No explicit when-to-use or alternative routing is provided, but the 'Every tool in the workspace' phrasing implies it is the enumeration tool for a full inventory. The optional workspace parameter guidance 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal one meaningful behavior: log lines are returned newest last. However, it does not mention potential latency, line format, access constraints, or error behavior, leaving some room for surprise.

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

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

Two short sentences, each earning its place: the first defines what the tool returns, and the second gives the practical use case. No filler or redundant restating of the schema.

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

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

Given its simplicity and fully documented parameters, the description contains what an agent needs to invoke it: what it returns, ordering, and when to use it. The absence of an output schema is mitigated by the explicit 'log lines' language, though a bit more detail on output format could push 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?

Schema description coverage is 100%, so the parameters are already well-documented. The description adds negligible parameter-level detail, but that matches the baseline expectation; it correctly refers to the tool being inspected.

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

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

The description clearly identifies the resource (the tool container's recent log lines) and the diagnostic purpose (finding why a tool is failing). It lacks an explicit verb like 'reads' or 'returns', but the intended action is unmistakable and distinct from all sibling 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 explicitly tells the agent when to use the tool: to find out why a tool is failing. It does not discuss when not to use it or compare with alternatives, but no sibling tool provides log access, so the guidance 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?

No annotations are provided, so the description must carry the full burden. It clearly indicates this is a read-only, informational tool (no side effects), which is inferred from the wording but not explicit. It does not describe what happens if the user is not in a workspace or how the 'domain margin' is calculated, but for a pricing query this is acceptable.

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

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

The description is a single, concise sentence that front-loads the core purpose ('What Boathouse charges') and then provides key details. No redundant words; every phrase adds 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?

The tool is simple (no required params, no output schema), and the description covers the key aspects of pricing. It does not mention pagination or return format, but those are not critical for a pricing inquiry. It is complete enough for an agent to call it confidently, though it could briefly note that it returns cost-related information.

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 100%, meaning the parameter 'workspace' is fully described in the input schema. The description does not need to add much, but it does not clarify how workspace affects the pricing information (e.g., does pricing vary by workspace?). This is a minor gap, but the baseline 3 is appropriate.

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

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

The description clearly states the purpose: it explains what Boathouse charges, specifying the pricing structure (one org plan, up to five tools, shared limits, storage, domain margin). This is specific and differentiates it from billing, topup, and usage 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?

The description implies this is for understanding pricing, but does not explicitly say when to use it versus 'billing' (which might be for invoices/payments) or 'usage' (for resource consumption). No exclusions or alternatives are named, leaving some ambiguity.

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 mentions the output format (text files, base64 for binary) and permission requirement (admin only). It does not explicitly state that the operation is read-only or side-effect free, though 'fetch' implies it. It also doesn't cover error handling, but the disclosed details are valuable.

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 sentences with zero waste. The purpose is front-loaded, followed by return format and permission. Every sentence adds necessary information 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?

The description covers the return format (release number, text/base64 files) and permission. It does not mention error conditions or pagination, but for a simple fetch with three parameters and a clear output description, it is sufficiently complete for an agent to call 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 covers all three parameters (tool, release, workspace) with detailed descriptions, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already states, such as the default for 'release' or the purpose of 'workspace'.

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 'fetch' and the resource 'source folder a release was built from', with a specific purpose (edit and deploy back). It also distinguishes itself from siblings like 'deploy' or 'releases' by focusing on retrieving source files for modification. The mention of returning release number and file content (with base64 for binaries) further clarifies its function.

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 the use case: when you need to obtain the exact source of a release to edit and redeploy. It also notes 'Tool admins only', which is a restriction. However, it does not explicitly compare with alternatives like 'releases' (listing) or 'deploy' (pushing), though the purpose is clear enough for an agent to infer when 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 adds useful context by explaining the referral deal (10% of usage charges, paid monthly in cash) and that earnings are cumulative ('so far'). However, it does not explicitly state that this is read-only or describe edge cases such as empty referral 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 dense sentence with no filler. It front-loads the most important items (referral code and link) and then gives the deal and earnings details. Every phrase contributes meaningful information.

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

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

For a low-complexity tool with one optional parameter and no output schema, the description covers the main return elements: code, link, deal, and per-workspace earnings. It is reasonably complete for an agent to know what to expect, though it does not clarify whose referral code is being returned or how the optional workspace parameter affects results.

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%, so the workspace parameter is already fully documented in the schema. The tool description adds no additional meaning about the workspace parameter, which is acceptable under the baseline, but it also does not enrich parameter understanding.

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

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

The description clearly identifies the resource (referral code, link, deal, and per-workspace earnings) and implies a read/retrieve operation, though it lacks an explicit verb like 'get' or 'list.' It is sufficiently distinct from sibling tools such as billing or usage because it focuses on referral-specific 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?

Usage is implied rather than stated: the description makes clear this tool provides referral information, but it does not explicitly say when to use it instead of alternatives like usage, billing, or share. There is no when-not or exclusion guidance, so the agent must 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?

With no annotations provided, the description carries the disclosure burden and does it well: it specifies the fixed 20-release scope, statuses, authorship/time, note content, and the special behavior that failed releases include the last build-log line. It does not mention auth or rate limits, but for a read-only-looking listing this is sufficient context.

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 subject in the first clause and the notable failure behavior in the second sentence. Every sentence carries useful information and there is no filler or repetition of schema details.

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 two-parameter listing with no output schema, the description covers the returned fields and the distinctive failed-release behavior, which is what an agent needs to interpret results. It lacks usage guidance and explicit read-only confirmation, but the schema covers invocation, so the description is nearly 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 100%, so the baseline is 3; the description adds no additional meaning about the 'tool' or 'workspace' parameters beyond what the schema already states. It only implies that the releases belong to a tool, which is already explicit in the 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 clearly identifies the resource as the last 20 releases of a tool and enumerates the fields returned, which makes the operation recognizable as a release-history listing. The verb is only implicit rather than explicit (e.g., 'list'), so it stops short of a 5, but it is distinct from siblings like deploy, rollback, and logs.

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 about when to use this tool versus alternatives such as logs, deploy, or rollback. There is no explicit context, prerequisite, or exclusion, so the agent must infer the appropriate use case from the tool name and listed fields.

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 it delivers meaningful behavioral context: the flow is asynchronous and human-mediated ('owners get an email with one Allow button; nobody there runs a command'), and the requester is notified on approval. This is the key behavioral trait an agent needs to set expectations that no immediate grant occurs.

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 with zero filler. The core purpose is front-loaded, then the mechanism, then the follow-up. Every sentence earns its place.

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

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

For an async approval tool with no output schema and no annotations, the description covers purpose, roles, the human-approval workflow, and the confirmation outcome. Minor gap: 'The person' is slightly ambiguous when the email recipient is never explicitly identified as the requester, and there's no mention of what happens on denial or what the tool returns.

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%, so the baseline of 3 applies; the schema already documents target format, tier enum, message, and workspace disambiguation. The description adds no parameter-specific details beyond what the schema provides, but it doesn't need to.

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 ('ask to be let into'), a specific resource ('a tool in someone else's workspace'), and the access tiers (viewer, editor, admin). The phrase 'someone else's workspace' clearly separates it from sibling set_access, which would grant access directly, and allow_request/access_requests, which handle the approval side.

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 this tool — when you need access to another workspace's tool rather than granting it yourself — but it never names an alternative or gives an explicit when-not. An agent must infer the distinction from the phrase 'someone else's workspace' and 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the container is restarted with current release and secrets, but doesn't mention potential downtime, whether it's disruptive to other tools, or if it requires special permissions. This is a gap for a mutating operation.

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

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

The description is one concise sentence that gets to the point immediately. It includes essential details (current release, secrets) without padding. It earns a 4 for clarity and efficiency, though it could be slightly more structured.

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 mutating tool with no annotations and no output schema, the description is somewhat minimal. It tells you what happens but not the consequences (downtime, side effects) or when to prefer an alternative. It's not inadequate, but could be more complete given the lack of structured safety hints.

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 100%, so the schema documents both parameters. The description adds context about using 'current release' and 'current secrets', but doesn't elaborate on the 'workspace' parameter's behavior beyond what the schema states. It's adequate but not compensating beyond baseline.

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 (restart) and the resource (the tool's container) with specific details (current release and secrets). It distinguishes from siblings like deploy and rollback by focusing on container restart, but doesn't explicitly differentiate, so it's 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 implies when to use it (when a tool needs a restart with its current configuration), but doesn't explicitly state when not to use it or mention alternatives like deploy or rollback. Context is implicit 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?

No annotations exist, so the description must disclose behavior itself. It usefully states that only software is rolled back, never the database, and that the default target is the preceding live release. It does not mention potential disruption, irreversibility, or permissions, so it only partially carries the burden.

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

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

Two short sentences front-load the core action and then add the database caveat. No filler or repetition of schema details. It is appropriately sized.

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 three-parameter tool with full schema coverage, the description gives enough to invoke rollback: target by default, explicit param `to`, and a clear scope boundary. It omits consequences like behavior when no prior release exists, but that is a minor gap. Overall complete enough for selection and 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 covers all three parameters fully, so the description is not required to re-document them. It does add a plain-language restatement of the default behavior for `to`, which aligns with the schema. This provides only marginal extra meaning over the already complete 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 opening clause 'Put an earlier release back in service' names a specific operation and target (release), and the final clause 'never the database' narrows scope. It is distinct from siblings like deploy or restart, though it does not explicitly name them. Minor lack of explicit differentiation keeps it just below 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?

Description states default behavior when `to` is omitted, which helps invocation, but gives no guidance on when to choose rollback over deploy/restart/releases. Usage is only implied by the verb and release context, with no explicit exclusions or alternatives. This is the minimum viable level.

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

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

No annotations are provided, so the description carries the full behavioral burden. It meaningfully discloses a non-obvious side effect: the secret does not disappear immediately but only on the tool's next restart or deploy. This goes beyond simply saying 'delete' and gives the agent accurate expectations.

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

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

Two short sentences communicate the core action and the key timing behavior with zero wasted words. 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 low-complexity destructive operation, this is fairly complete: the description states what is removed, the target scope, and the delayed effect. The lack of an output schema is mitigated by the clear behavioral outcome, though mentioning that secrets_list can be used to find existing secret names would have been a small addition.

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%, so the schema already documents all three parameters. The description's mention of 'one secret' and 'from a tool' lightly reinforces the name and tool parameters, but it adds no substantive 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?

The description states a specific action ('Remove one secret') and a specific resource ('from a tool'), which clearly distinguishes it from sibling tools like secrets_list, secrets_set, and delete_tool. The scope is precise and immediately understandable.

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: this is the tool to delete a secret from a tool. However, there is no explicit guidance about when to prefer this over secrets_set or how workspace selection affects the operation, so the agent must infer usage from the purpose.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly states 'Values are never returned,' which is a critical guarantee, and adds detail about the metadata returned (last set and by whom). It doesn't mention permissions or pagination, but the core behavior is clearly 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?

A single, tight sentence that front-loads the primary output (names of secrets) and includes the key caveat (no values). Every word earns its place, 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 simple listing tool with two well-documented parameters and no output schema, the description sufficiently covers what the agent needs to know: what is returned (names, timestamps, owners) and a safety guarantee (no values). It lacks explicit pagination/ordering details, but these are minor for this scope.

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 100% with both parameters (tool, workspace) documented. The description doesn't add any additional meaning beyond what the schema provides, so it remains at the baseline for high coverage. No extra context on parameter usage is given.

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 lists secret names along with last-set time and who set them, with a specific verb ('list') and resource ('a tool's secrets'). It implicitly differentiates from siblings like secrets_set and secrets_delete by emphasizing metadata rather than values, but doesn't name them 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?

The purpose makes it obvious this is for reading secrets, not modifying them, but there's no explicit guidance on when to use it versus alternatives (e.g., secrets_set or secrets_delete). No exclusions or conditions are given, leaving usage 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 full burden and does meaningful work: it states that the secret becomes an environment variable, that the tool is restarted, and that the value must not be echoed back to the user. This reveals side effects and security expectations beyond what the bare parameter names imply.

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 with no filler: the core action, the key side effect, the naming rule, and a critical security instruction. The most important operational fact 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 setter with no output schema, the description covers the essential side effect (restart) and the security invariant (never echo). It does not state whether an existing secret is overwritten or what response to expect, but for this operation those gaps are 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?

Schema coverage is 100%, so the baseline is 3. The description reinforces the UPPER_SNAKE_CASE convention and the injection behavior, but it does not add substantial new meaning about the tool, workspace, or value parameters 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-plus-resource construction, 'Set one secret on a tool,' and clarifies the payload is a single secret injected as an environment variable. This clearly distinguishes the operation from sibling secrets_delete and secrets_list without needing to read their 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 implies the tool is for creating/replacing a secret rather than listing or deleting secrets, but it does not explicitly say when to prefer this tool or when to use an alternative. 'Never echo the value back to the user' is useful behavior guidance, not usage-vs-alternative guidance.

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

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

No annotations are provided, so the description must carry the full burden. It fails to disclose side effects (e.g., does it override existing shares?), reversibility, permission requirements, or the existence of the 'public' mode which is present in the schema but not mentioned in the description. This is a significant gap for a mutation 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 a single, focused sentence with a colon introducing the modes. It front-loads the core purpose and then clarifies options. It is concise and efficient, though the omission of the 'public' mode could be seen as a structure 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 tool with 4 parameters and no output schema, the description is incomplete. It fails to mention the 'public' mode allowed by the schema, does not explain what happens to existing access settings when changing modes, and omits any prerequisites or consequences. An agent would need to infer or look elsewhere for critical behavior.

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%, so the schema already documents all parameters. The description adds extra meaning for the 'mode' parameter (explains members vs listed) but does not clarify 'public' (which the schema does) or add context for tier/tool/workspace beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific action ('Set who a tool is open to by default') with clear explanations of the two main modes. This distinguishes it from sibling tools like share/unshare (explicit sharing) and access_requests (request handling) by emphasizing the 'default' 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?

Provides a single recommendation: 'Use listed for anything sensitive.' However, it doesn't explicitly contrast with alternatives like share or access_requests, nor does it state when not to use this tool. The context of setting default access is clear but not elaborated.

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 it does so well. It discloses that viewer access is read-only via gateway write blocking, that new users receive an emailed invitation when configured, and that the result contains an emailed flag to check for delivery failure. This goes beyond a generic 'share' statement, though it does not cover authorization prerequisites or idempotency when re-sharing.

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: purpose first, then tier semantics, then the invitation workflow. Every sentence contributes either to selecting the tool or executing the call correctly, with no filler or repetition of schema details.

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 5 parameters, no output schema, and no annotations, the description covers purpose, tier permissions, invitation behavior, and post-call verification. It does not address preconditions like required owner/admin privileges or what happens if the person already has access, but those are secondary given the accessible schema and detailed narrative.

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 already covers all 5 parameters at 100% coverage, so the baseline is 3. The description adds real value by explaining what each tier actually permits (viewer/editor/admin), which the schema enum does not convey. It also frames email as the recipient identifier and gives actionable meaning to the result via the emailed check.

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 a specific verb and resource: 'Give one person access to one tool by email, at a tier.' It also defines the three tiers in concrete permission terms, which clearly distinguishes sharing from sibling operations like unshare, set_access, or users_invite.

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 conveys clear context: per-person, per-tool, email-based sharing with tier semanticsows. It explains what happens for new users and the email delivery fallback. However, it never explicitly mentions when to prefer this over alternatives such as request_access, allow_request, set_access, or users_invite, leaving some routing 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 full burden and does so well: it discloses payment location/actor, quote-vs-confirm behavior, idempotent retry via operation_id, amount bounds, and owner-only authorization. These are exactly the non-obvious traits an agent needs before calling.

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 dense sentences, all load-bearing, with purpose first and constraints last. No filler or redundancy with the schema.

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

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

For a payment tool with no output schema or annotations, the description is complete: it defines the flow, required inputs at each stage, retry behavior, amount range, and permissions. An agent can determine how to quote, confirm, and retry without external information.

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

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

The input schema already covers 100% of parameters, but the description adds normative semantics: cents must be between 500 and 100000, operation_id comes from the quote and must be reused, and confirm gates actual execution. This goes beyond the schema's generic descriptions.

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 ('Open secure Stripe checkout') and resource ('prepaid hosting credit'), and adds that the owner completes payment in Stripe. This clearly differentiates it from general billing or pricing tools by its checkout-and-credit 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?

It gives an explicit two-phase workflow: omit confirm to quote, then confirm with matching cents and operation_id after approval, and reuse operation_id on retries. It doesn't name sibling alternatives or exclusions, so it's not a 5, but the invocation conditions are clear.

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 disclosing behavior. It clearly states the main effect (removing access) and the crucial detail that the user keeps their workspace account, which prevents misinterpretation. However, it does not mention potential side effects, required permissions, or error handling, leaving some ambiguity for a mutation 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 extremely concise and effective, with two sentences that immediately state the action and the key qualifier about the account. Every word serves a purpose, 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 simple revocation tool with full schema coverage, the description covers the core functionality and the key distinction from user removal. However, it lacks guidance on when to use this versus related tools, and it does not mention the optional workspace parameter or any prerequisites, leaving some contextual gaps that an agent might need.

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%, so the schema already documents all parameters. The description adds no additional parameter meaning or usage context beyond what the schema provides. The baseline of 3 is appropriate since the schema fully covers the 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 states a specific action ('take away one person's access to one tool') with a clear resource (a specific tool) and subject (a person). It distinguishes itself from siblings like 'share' or 'set_access' by implying the opposite of granting access, and it clarifies that the user's account is preserved, which is a key differentiator from 'users_remove'.

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

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

The description implies usage for revoking a single user's access to a single tool but does not explicitly compare to alternatives or provide when-not-to-use conditions. Given the sibling tools like 'share', 'set_access', and 'users_remove', the agent might need additional guidance on selecting this tool, but the core intent is clear enough for a basic call.

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

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

With no annotations, the description carries the full burden. It clearly states the tool reads resource metrics, implying a read-only nature, but does not disclose output format, error behavior, or authorization details beyond 'Tool admins only'. For a simple check tool this is adequate but not rich.

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

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

A single, front-loaded sentence with no filler. Every word adds value, stating the action and the scope.

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 check tool with two well-documented parameters and no output schema, the description covers the essential purpose and access restriction. It could mention what the returned data looks like, but that is minor for this tool.

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

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

Schema description coverage is 100% and both parameters are described in the schema. The tool description adds no extra meaning beyond what the schema already provides, so 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 uses a specific verb ('Check') and names the exact resources (storage, memory, CPU) plus the pause reason. It clearly distinguishes from sibling tools like 'logs' or 'capacity' by the specific items checked.

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?

It includes a usage restriction ('Tool admins only') but does not mention when to use this tool versus alternatives like 'capacity' or 'get_tool'. No explicit when-not or alternative routing is given.

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

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

With no annotations, the description must disclose behavioral traits. It states it returns a one-time invite link for new users and is owner-only, but it does not describe side effects of role changes, whether changes are reversible, or error handling. The description carries the burden and only partially fulfills it.

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

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

The description is efficient, front-loading the core action, then providing role definitions and the owner restriction. Each sentence adds value without excessive verbosity.

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 three parameters and no output schema, the description covers roles, return value for new users, and permission. However, it does not explain behavior for role changes (e.g., whether an invite link is also returned) or mention the workspace parameter's importance in multi-workspace scenarios, which is left to the schema.

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

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

Schema coverage is 100%, but the description adds significant meaning to the role parameter by defining each enum value (owner, member, guest) with concrete implications. This goes beyond the schema's simple 'Default member.'

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 adds a person or changes their role, using a specific verb and resource. It distinguishes from siblings like users_invite by explicitly covering role changes, though it does not name the sibling directly.

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 'Owners only' as a permission constraint but provides no guidance on when to use this tool versus alternatives like users_invite or users_remove. There is no explicit when/when-not guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses the email side effects (new accounts get a confirmation link, established accounts get a sign-in URL) and clarifies password-reset behavior (only the account holder's mailbox gets the reset link). It does not cover failure modes or permissions, but for a simple resend action the core behavior is visible.

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 purpose is front-loaded in the opening sentence and the additional sentences earn their place by explaining email outcomes and the reset-link behavior. The phrase 'Check emailed' is slightly cryptic and the reset detail is tangential, so it is not perfectly polished.

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 two-parameter tool, the description explains what happens on success and offers a practical fallback check. However, with no output schema or annotations, it omits return/error behavior and the prerequisite that the person must already have an invitation, leaving some ambiguity for an agent.

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 description adds nothing about the email or workspace parameter beyond what the schema already documents. It refers to 'someone in the workspace' but supplies no new syntax, constraints, or format guidance, so 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 first sentence is a precise verb-resource statement: 'Resend an invitation to someone in the workspace.' This distinguishes it from users_add (initial invite) and users_remove, though it never names those siblings and does not explicitly state that it is not for first-time invites.

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 practical context: new vs established accounts and a directive to 'Check emailed before offering a fallback.' It implies when the tool is appropriate but does not explicitly state when to use it instead of users_add or how to handle an uninvited email.

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 disclosure burden. It usefully discloses the output contents: all workspace members, their roles, names, and password-set status. However, it does not mention authorization requirements, pagination, error behavior, or whether the results are sorted or filtered.

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 no wasted words. It front-loads the key scope ('Everyone in the workspace') and then enumerates the useful output attributes. Every element contributes to understanding the tool.

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

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

The description is adequate for a simple list tool but leaves some gaps: no explicit statement that this is a read-only operation, no guidance on the optional workspace parameter, and no mention of behavior like requiring membership. Because there is no output schema, the field list in the description helps, but broader usage and edge-case context are 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% for the single optional workspace parameter, so the schema already documents its meaning. The description adds minimal parameter-related value; it only implies the workspace context by saying 'in the workspace.' This matches the baseline for high schema coverage.

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

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

The description defines the resource as all workspace members and specifies the returned fields (role, name, password set), which makes the tool's purpose reasonably clear. It lacks an explicit verb like 'list', but the tool name and the enumeration phrasing convey the read operation. It does not explicitly contrast with sibling tools, though the name already distinguishes it from users_add and users_invite.

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 whoami, users_add, or users_remove. It also does not explain when to pass the optional workspace parameter, even though the schema hints that whoami lists available workspaces. Usage context is only implied by the tool name and phrasing.

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

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

With no annotations, the description carries the full burden and does well: it discloses the destructive consequences ('sessions, project keys, invites and tool grants stop working immediately') and the authorization requirement ('Owners only'). It stops short of stating reversibility or re-addability, but the immediate-effects disclosure is substantive.

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

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

Two tightly packed sentences in logical order: action → consequences → permission. Every clause earns its place; there is no filler or restatement of what the schema already documents.

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 destructive, owner-gated tool with two fully documented parameters, the description covers the core operational facts: what is removed, what stops working, and who may call it. Minor gaps are error conditions (e.g., email not found) and reversibility, which are secondary for a removal action.

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% — both email and workspace already have descriptions, so the baseline is 3. The tool description adds no parameter-level meaning beyond the schema; its permission note ('Owners only') relates to the caller, not the 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?

States a specific verb and resource — 'Remove a person from the workspace' — and adds distinguishing behavioral detail (sessions, project keys, invites, and tool grants stop working) that clearly separates it from sibling tools like users_add, users_invite, and users_list.

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 — permanent removal with immediate revocation — and flags the 'Owners only' eligibility gate. However, it never explicitly names alternatives or says when not to use it, such as when only access should be revoked rather than the person removed (set_access, unshare).

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

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

With no annotations, the description carries the behavioral burden. It states what the tool returns and implies a safe, read-only contextual lookup by calling it a first step, though it does not explicitly say 'makes no changes'.

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

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

Two sentences with no filler: the first names the output fields, the second gives usage guidance. Information is front-loaded and every sentence earns its place.

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

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

For a simple lookup tool with no required parameters and no output schema, the description covers the returned fields and gives a clear use case. The optional workspace behavior is already documented in the schema, so nothing necessary is missing.

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

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

The input schema already fully documents the optional workspace parameter, including when to use it. The description's mention of workspace aligns with the schema but does not add new parameter-level meaning beyond it.

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

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

The description clearly identifies the tool as an identity/context lookup, listing the exact fields returned: email, workspace, domain, and prepaid balance. It distinguishes itself from the many sibling tools by framing itself as the first call for workspace orientation.

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?

It provides an explicit trigger: 'Call it first if you are not sure which workspace you are acting in.' It does not name exclusions or alternatives, but for a self-identification tool this is clear enough context.

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