Capital Company

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

Annotations already carry readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so 'Changes nothing' largely restates the structured safety profile. The one genuine addition is 'in Capital Company's words', which hints the answer is quoted from records rather than synthesized, but it is not developed.

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 with the core behavior front-loaded; nothing is padded. 'Changes nothing' is close to redundant with the readOnlyHint annotation, which slightly dilutes an otherwise tight description.

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

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

For a read-only Q&A tool with full schema coverage and annotations, the essentials are present. With no output schema, the description does not indicate what the answer looks like (verbatim quotes, sources, scope limits), and no guidance on how the free-text request is interpreted or how far back records are searched.

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 team, request, and timeZone are fully documented in the schema, including the conditional rule for supplying team. The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

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

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

States a specific verb+resource: answers a question about the user's team and funds drawn from Capital Company records. It implicitly distinguishes itself from write siblings (create/update/send) by stating it changes nothing, but it never names a sibling like capital_company_conversation or capital_company_reply to clarify the routing boundary.

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: an agent can infer this is the read-only Q&A path versus the many mutation siblings. There is no explicit when-to-use, when-not-to-use, or alternative named, so the agent must infer the boundary with capital_company_conversation and capital_company_reply.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds that it sends an email and creates an object upon link opening — useful side-effect disclosure beyond the annotations. However it doesn't state permissions, whether the created entity is replaceable, rate limits, or idempotency. Some behavioral value, 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?

Two sentences, front-loaded with the target user scenario and the action. Efficient, though the first sentence is a long conditional clause that slightly delays the core action.

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

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

With 3 required params, no output schema, and only openWorldHint from annotations, the description should convey more about side effects (account creation, verification flow) and what the caller gets back. It covers the trigger and outcome but leaves gaps around return behavior and error cases.

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 each parameter (email, timeZone, confirmationId) is already documented in the schema. The description adds only that the email link goes to the sign-in address and that confirmationId is 'what they said yes to', echoing the schema. No syntax or format 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 explains the tool sends a verification email and that opening it verifies the address and creates the thing the user agreed to. But the verb+resource is vague — 'emails a link' rather than a clear imperative name like 'send verification email'. It describes a workflow rather than stating a crisp purpose.

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

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

The description gives a narrow scenario ('someone who started without an account and said yes to a proposal'), which implicitly tells when to use it, but never explicitly compares to siblings like capital_company_confirm or capital_company_ask. No when-not or alternative guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real context beyond them: 'Confirming runs the operation' tells the agent this commits the pending action, and the decline path describes the follow-up flow. It does not discuss permissions or idempotency, but the consequence disclosure is valuable given the destructive annotation.

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

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

Two compact sentences with no filler; the core action is front-loaded and the branching consequences follow immediately. Every clause carries 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 three-parameter destructive tool with no output schema, the description covers the essential outcome of each decision path, and the schema plus annotations carry the rest. It is complete enough to invoke correctly, though it could note the dependency on a prior assistant-generated confirmationId.

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 confirmationId, decision, and timeZone are already documented in the schema. The description merely echoes the confirm/decline dichotomy and adds no format or sourcing detail beyond what the schema provides, matching the baseline 3 for high-coverage schemas.

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 (relaying the user's confirm/decline answer) and the resource (a Confirmation put by the assistant), which is distinct from the sibling capital_company_show_confirmation. It stops short of explicitly contrasting itself with that sibling, so it is clear but not fully self-differentiating.

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 explains the two branches of use — confirming runs the operation, declining lets the assistant ask what to change — which implies when each decision applies. However it never names an alternative tool (e.g., show_confirmation) or states prerequisites such as needing a confirmationId from a prior assistant message, so guidance remains implicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuine value beyond that by disclosing the shape of the response: conversation content plus the outcome of confirmations and a waiting-on-user flag.

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

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

One sentence, front-loaded with the verb and resource, with the two payload qualifiers appended compactly. 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?

With no output schema and only one optional parameter, the description carries the return-value burden and does so adequately by naming what the read yields (confirmation outcomes, waiting state). Minor gap: no indication of conversation history length, ordering, or whether past conversations are retrievable.

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

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

Schema description coverage is 100% and the single 'team' parameter is fully documented in the schema, including the conditional 'only when the user belongs to more than one team.' The description adds nothing about parameters, 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?

States a specific verb+resource: 'Reads the user's current conversation with Capital Company's assistant.' It also scopes the payload (confirmation outcomes, waiting state), which separates it from write-oriented siblings like capital_company_reply or capital_company_confirm. It stops short of naming those siblings explicitly.

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

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

Usage is implied rather than stated — the agent can infer this is the tool for checking conversation state, and the mention of 'whether it is waiting on them' hints at a status-check use case. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., capital_company_show_confirmation).

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

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

Annotations declare readOnlyHint=false and destructiveHint=false but say nothing about flow. The description adds real behavioral context: the assistant resolves fund and investor, solicits missing details, and requires user confirmation before anything is persisted — i.e., this is a draft-then-confirm mutation, not an immediate write. That is meaningful value beyond the annotations, though rate limits, permission requirements, and failure modes are unaddressed.

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 no filler, front-loaded with the action and followed by the interaction flow. Every clause earns its place and nothing is repeated from the title or 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?

With no output schema, the description responsibly covers what the tool does and that a confirmation step precedes any write, which is the key thing an agent must know before calling. It stops short of describing what the tool returns or what happens on rejection, leaving a small 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?

Schema description coverage is 100% (request, timeZone, team all documented), so the schema already carries parameter meaning and the baseline of 3 applies. The description only loosely signals that fund and investor come from the free-text request rather than dedicated params, adding marginal clarification.

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

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

The description gives a specific verb+resource: recording a new commitment by an investor in one of the user's funds. It is clearly distinct from edit_commitment in intent (new vs. modify), though it never names that sibling explicitly. A capable agent can identify the operation without opening the schema.

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

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

Usage is implied: use this when an investor makes a commitment to a fund. The confirmation-before-write note hints at the workflow, but there is no explicit when-not guidance and no named alternative (e.g., edit_commitment for existing commitments, show_confirmation for reviewing a draft).

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's added value is the workflow: the assistant fills gaps and requires user confirmation before creation. That is meaningful non-obvious behavior beyond the annotations, though no mention of failure, permissions, or what happens on confirmation.

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

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

One dense sentence plus a sentence on the interactive flow. Front-loaded with the action and resource, no filler. Slightly overloaded but coherent.

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 non-mutating-in-effect create-starter with no output schema, the description covers artifact types, captured fields, and the confirmation gate. Lacks detail on what the tool returns or how the conversation continues, but sufficient to invoke 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%, so the schema already documents request, timeZone, and the conditional team parameter. The description adds no parameter-level detail (e.g., that `request` carries the user's own words), 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?

States a specific verb (create) and resource (fund), and distinguishes the artifact types it handles — SPV or blind pool — with the fields it captures. An agent can separate this from capital_company_update_fund and the commitment siblings without opening 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?

Implies the tool kicks off a multi-step create flow, but gives no explicit when-to-use versus siblings like capital_company_ask or capital_company_update_fund. Usage is inferable from the flow description rather than stated as a routing rule.

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

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

Annotations only declare that this is non-read-only, non-destructive and closed-world. The description adds genuinely new behavior: the edit is two-phase, requiring user confirmation before any write, and it can ripple into already-sent capital calls. It stops short of saying which fields are editable or what the confirmation flow returns.

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 written sentences with zero filler. The scope constraint (only named fields) is front-loaded and the confirmation caveat follows immediately.

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 output schema, the description covers the essentials an agent needs: it edits an existing commitment, only named fields, and the change is gated on user confirmation. Missing only which fields exist and how the paired confirmation call fits in.

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 the team, request and timeZone parameters. The description only echoes that the 'fields they name' drive the edit, adding no syntax or format detail beyond what the schema provides.

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

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

States a specific verb (edit) and resource (an existing commitment) scoped to the user's funds, and clarifies that only the fields the user names are touched. It implicitly separates itself from capital_company_create_commitment, but never names a sibling 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?

It conveys the workflow context (the edit is staged and shown to the user for confirmation before writing), which implies the follow-up confirmation step. However it never states when to prefer this over create_commitment or update_fund, and gives no exclusion criteria.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows this initiates an action rather than a pure read. The description adds valuable behavioral context: the assistant resolves the fund, asks for missing info, and requires user confirmation before sending. This confirms a safe, non-destructive flow with a confirmation gate, going beyond structured annotations.

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

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

Two sentences, front-loaded with the core action and then the workflow. No redundancy or filler; every clause earns its place.

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

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

The description covers the tool's purpose, the confirmation workflow, and the fact that missing information is requested. With no output schema and annotations covering safety hints, the description is complete enough for an agent to invoke it correctly, though it could clarify what 'resolves the fund' entails.

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 input schema fully documents all three parameters (team, request, timeZone). The description adds no additional parameter-level detail, so 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 verb+resource: 'inviting investors to one of the user's funds by email address.' Clear what the tool does. However, it doesn't distinguish from siblings like capital_company_send_capital_calls or capital_company_create_commitment, which also involve investor-facing communications.

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

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

The description implies usage (when the user wants to invite investors) but doesn't explicitly say when to use this tool vs alternatives like capital_company_send_capital_calls or capital_company_create_commitment. No exclusions or prerequisites are stated.

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

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

Annotations only cover safety flags (readOnlyHint=false, openWorldHint=false, destructiveHint=false), so the description's disclosure of the response contract — the assistant either asks another question or proposes something to confirm — adds real value since no output schema exists. It does not, however, explain the write implication of readOnlyHint=false or what happens if no question is pending.

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, well-formed sentence that front-loads the core action and appends the return behavior. No wasted clauses or redundant restatement 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 3-parameter tool with full schema coverage and no output schema, the description covers the essential round-trip: answer goes in, next assistant turn comes out. It is nearly complete but omits error/edge behavior such as a missing prior question or authentication expectations, keeping it short of a 5.

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 all three parameters (team, answer, timeZone) are already documented in the schema, including the conditional 'only when the user belongs to more than one team' rule for team. The description only echoes 'in their own words' for answer and adds nothing new, 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 gives a specific verb and resource: it relays the user's answer to Capital Company's last assistant question and returns the assistant's next turn. This is clearly distinct in flavor from the sibling capital_company_ask (which poses a question) and capital_company_confirm, though it never names those siblings explicitly to sharpen the contrast.

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

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

Usage is implied by the phrase 'the question Capital Company's assistant asked last,' which tells the agent this follows an ask. However, there is no explicit statement of when to use this versus capital_company_confirm or capital_company_conversation, and no preconditions or exclusion 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?

Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context beyond them: the assistant resolves the class and its commitments and presents notices for user confirmation before anything is sent, and it never moves money. This goes beyond the structured fields, though the send/confirmation mechanics could be spelled out further.

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

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

Three short sentences, front-loaded with the action and followed by the confirmation and no-money guarantees. No filler, though the description is not maximally tight.

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?

Annotations cover the safety profile and no output schema is needed since the description explains the flow ends in user confirmation. For a non-destructive send tool, the description covers purpose, resolution behavior, and the confirmation gate adequately; minor gaps remain around return/next-step details.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds no parameter-level detail (e.g., format of request or team handling), 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?

States a specific verb and resource: 'Starts sending capital call notices to the investors of a fund class.' An agent can identify the action without opening the schema. However, it does not explicitly differentiate itself from the sibling capital_company_send_subscription_agreements, which is a closely analogous send operation.

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

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

Usage is implied by the resource scope ('investors of a fund class') rather than stated as when-to-use guidance. No explicit when-not conditions or named alternatives are given, so the agent must infer that this is the tool for capital calls specifically vs subscription agreements.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/safe profile is covered. The description adds real value beyond that: it discloses that the assistant resolves fund and commitments, and that nothing is sent until the user confirms — a material safety behavior for an outbound-signature action.

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, the action stated first and the confirmation safeguard second, with no filler. Slightly efficient rather than exemplary, but every clause carries 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 mutation tool with no output schema, the description covers the key agent-facing questions: what it sends, to whom, and that a confirmation gate precedes any dispatch. It leaves unspecified what the call returns or whether dispatch is asynchronous, which a caller would need to know.

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 team, request and timeZone are already fully documented by the schema; the description adds no syntax, format, or constraint detail for any of them. Baseline 3 applies when the schema does all the work.

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: starting the send of subscription agreements for signature to a fund's investors. That is clearly distinguishable from siblings like capital_company_send_capital_calls or capital_company_invite_investors by the artifact involved, though the description never names an alternative to route against.

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 context is implied by 'for signature to investors of one of the user's funds' and by the confirmation step, but there is no explicit statement of when to pick this over send_capital_calls or invite_investors, nor any precondition (e.g. commitments must exist) beyond the internal resolution step.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false. The description's 'Changes nothing' reinforces the read-only profile but adds essentially no behavioral context beyond what the annotations state, such as whether the confirmation expires or what the card displays.

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?

Short and front-loaded with the action, but the middle clause ('named in Capital Company's reply on Capital Company's card') is repetitive and awkward, slowing comprehension without adding precision.

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, single-parameter tool with no output schema and strong annotation coverage, the description is minimally adequate. It leaves the relationship to capital_company_confirm unstated, which an agent would benefit from given the crowded sibling set.

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 confirmationId parameter, and its schema description mirrors the tool description. The description adds no format, sourcing, or lookup guidance beyond what the schema already documents, 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?

States a specific verb+resource ('Shows ... a Confirmation') and clarifies scope by saying the user confirms or declines it themselves, which implicitly distinguishes it from the sibling capital_company_confirm. The phrasing 'named in Capital Company's reply on Capital Company's card' is convoluted but the core action is identifiable.

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

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

Usage is only implied: by saying the user confirms/declines the confirmation themselves, it suggests this is the display step preceding an actual confirm/decline. No explicit when-to-use rule or direct reference to the sibling capital_company_confirm 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the call only STARTS a change and nothing is written until the user confirms — important because it explains why capital_company_confirm/show_confirmation exist and why a 'success' here may not mean persisted 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?

Two short sentences, front-loaded with the action and scope, followed by the confirmation constraint. No filler and nothing redundant.

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

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

For a mutation tool with no output schema, the description covers the essential mechanics: it's a partial, confirm-gated update limited to named fields. It could say more about what happens after confirmation or what a caller should expect back, but nothing critical is missing.

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

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

Schema description coverage is 100% with 3 well-documented parameters (team, request, timeZone), so the schema carries the burden. 'The fields they name' loosely maps to the free-text request parameter but adds no format or constraint detail beyond the schema, 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?

It names a specific verb and resource ('changing settings of one of the user's funds') and scopes it precisely ('the fields they name, nothing else'). It does not explicitly distinguish itself from siblings like capital_company_create_fund or capital_company_edit_commitment, 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?

The description implies the usage context (an assistant-mediated change flow) and hints that changes require confirmation, but it never states when to choose this over create_fund or edit_commitment, nor any exclusions. Adequate but leaves 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds real context beyond that: no sign-in is required, and it explains the downstream flow (login link email, sign-in, connecting the assistant). It still doesn't say whether creation is idempotent or what happens if a workspace already exists.

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?

Purpose and scoping condition are front-loaded in the first sentence, and the total length is short. The trailing clause about signing in and connecting the assistant is useful but reads as a slightly loose run-on.

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

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

With annotations covering the safety profile and the schema fully documented, the only remaining gap is the return value — there is no output schema and the description never says what is returned (e.g., a workspace identifier or confirmation). For a simple three-parameter creator this is a minor omission.

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

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

Schema description coverage is 100% with three fully documented required parameters, so the schema carries parameter meaning. The description references email/account and firm team only at a narrative level and adds no format or constraint detail beyond the schema — the baseline 3 applies.

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

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

States a specific verb and resource — "Opens a Capital Company workspace" — with the scoping condition "for someone who has none: their account and their firm's team." This implicitly separates it from the sibling capital_company_* tools that operate inside an existing workspace, though no sibling is named 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?

"For someone who has none" gives a clear when-to-use condition, and "Needs no sign-in" surfaces the auth precondition (or absence of one). No explicit alternatives or when-not guidance are given, but the intended context is unambiguous.

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