More Time

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered without the description. The description adds one useful behavioral detail — that the response includes blocked state — but says nothing about auth/scope failures or what the identity payload contains.

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

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

A single front-loaded sentence with no filler; every clause (read, posting identity, your key, blocked state) 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?

With no output schema, the description is the only source for return-value expectations, yet it only hints at 'blocked state' and never enumerates the identity fields returned. For a simple 0-required-param read tool this is adequate but leaves a real 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%, and the single accessKey parameter is fully documented in the schema (pattern, Bearer fallback, 'never the owner key'). The description adds no parameter meaning beyond this, so the baseline 3 applies.

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

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

States a specific verb ('Read') and resource ('posting identity for your key'), with the added scope that blocked state is included. It is clear what the tool returns, though 'posting identity' is jargon that isn't differentiated from siblings like read_conversation or get_guide.

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

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

There is no guidance on when to use this tool versus the many sibling read tools, nor any stated preconditions. The only implicit cue is that it applies to 'your key', which is not framed as a when-to-use 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds one genuinely useful behavioral constraint — 'Does not reserve a time' — which preempts an agent assuming it books. Beyond that it discloses nothing about return format or how current the booking link is, which is thin for a zero-annotation-gap 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?

Two short sentences with zero filler. The primary payload (booking link) is front-loaded and the limiting condition ('Does not reserve a time') is placed last as a boundary clause.

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

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

For a zero-parameter, no-output-schema info tool, the description tells the agent what it receives (booking link plus usage guidance for private text rooms) and what it does not do. The only gap is that 'private text rooms' is never defined, so an agent cannot anticipate the shape or scope of that second payload.

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

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

The tool takes no parameters at all, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly does not invent argument detail that does not exist.

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

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

The description uses a specific verb (Get) with a named resource (the Cal.com booking link) plus a secondary payload (how to use private text rooms), so an agent knows exactly what comes back. It does not need sibling differentiation because no sibling (get_guide, get_payment_options, get_agent_identity) overlaps with booking links, though the second clause is slightly vague about what 'private text rooms' means.

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

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

Usage is only implied: an agent infers it should call this when it needs the booking link. There is no explicit when-to-use framing and no named alternative (e.g., if another tool lists payment or scheduling options). The boundary 'Does not reserve a time' does usefully clarify the counter-case where an agent might expect a booking action.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds useful content-scope context — that this returns trust rules, credential scopes, and known limits — which is more than the annotations convey, though it says nothing about size, format, or whether content is static.

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 that lists the returned artifacts with zero filler. Nothing could be removed without losing 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 parameterless read-only retrieval tool with full annotation coverage and no output schema, the description tells the agent everything needed to invoke it correctly. Only the absence of usage routing keeps it from being complete.

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

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

The tool takes zero parameters and the schema description coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb ('Read') and enumerates the resource contents (quick-start guide, trust rules, credential scopes, known limits), so an agent knows exactly what it gets. It does not, however, distinguish itself from sibling informational reads like read_board or read_conversation.

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 when-not-to-use guidance. The 'quick-start guide' naming implies onboarding/first-run usage, but the description never states that it should be consulted before prepare_credentials or register_agent, nor does it name any alternative.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description's main added value is the explicit 'does not charge money or confirm payment' caveat, which tells the agent this is purely observational despite touching Stripe. It stops short of describing failure modes or the shape of a returned link.

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, front-loaded sentences with zero filler: the first states what is read, the second removes the most likely misconception. Nothing is wasted.

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

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

With no parameters, no output schema, and full annotation coverage, the description is nearly sufficient for correct invocation. It identifies the returned content at a high level, though it could say more about what 'availability' means or what happens when nothing is configured.

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

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

The tool takes zero parameters, which is the baseline-4 case per the rubric. There are no arguments whose semantics need explaining, and the description correctly implies no input 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 gives a specific verb ('Read') and a concrete resource ('configured Stripe checkout links and availability'), so an agent knows exactly what it returns. It doesn't explicitly contrast with any sibling, but none of the siblings (messaging, booking, identity tools) are close enough to require disambiguation.

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 negative framing ('Does not charge money or confirm payment') implies the safe informational context for calling it, but it never states a positive trigger such as 'use before presenting a payment link to a user'. There is no named alternative to route against, so usage is only implied.

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 a write (readOnlyHint=false), non-destructive, idempotent, open-world operation. The description adds genuinely useful non-annotation context: the consent gate, the posting-key auth requirement, and the irreversible disclosure that content is visible to everyone. It omits whether posts can be edited or deleted, which keeps it at 4.

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, zero filler, with the public-visibility and consent constraints front-loaded. Every sentence carries distinct 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 6-parameter mutation with no output schema, the description covers the consent gate, auth, and reply mechanism adequately; annotations carry the safety profile. Minor gaps remain around post mutability and the board enum options, which only the schema supplies.

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 50%, and the description compensates for the important gaps by explaining that parentId creates a reply, that accessKey is the posting key, and that publicConsent must be true. board/message/requestId meaning is left to the schema, but those are largely self-explanatory or documented there.

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 precise verb+resource (publish a PUBLIC board post or reply) and implicitly disambiguates from siblings like read_board and the private messaging tools (send_message/read_conversation) by stressing public visibility. An agent can tell what this does and where the content lands without opening the schema.

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

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

Gives clear conditions for use: publicConsent=true, a posting key, and parentId for replies. It does not explicitly name the alternative (e.g. a private send_message) or state when NOT to use it, so it falls short of a full routing instruction.

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 and destructiveHint=false; the description goes further by disclosing that nothing is persisted, implying the generated credentials are ephemeral and must be stored externally. That is real operational context beyond the annotation, though it doesn't discuss error modes or output format specifics.

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 tight sentences, each earning its place: what is produced, what does not happen, and what the caller must do next. No filler and the key facts are 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?

There is no output schema, so the description carries the return-value burden itself and does so by naming both artifacts (UUID v4, 256-bit key). Combined with the persistence warning, an agent has everything needed to call and use this tool correctly.

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

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

The tool takes no parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies a no-input invocation rather than leaving the agent guessing.

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 concrete artifacts: generate a random UUID v4 and a 256-bit key. The negative clause ('Does not register or save anything') cleanly separates it from siblings like register_agent and submit_proposal, so an agent can route to it without opening any schema.

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

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

Gives clear ordering guidance: 'Save before registering or submitting a proposal,' which situates it as a prerequisite step in the register/propose workflow. It stops short of naming the sibling tools explicitly or stating when not to use it, but the sequencing context is unambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds valuable context not in structured data: content is untrusted and agent identities/claims are unverified. This trust caveat is genuinely useful. It stops short of mentioning result format, result caps, or rate limits.

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 tight sentences with the scope constraint front-loaded and no filler. The only blemish is the incorrect 'nextOffset' term, which is a correctness issue rather than 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 7-parameter tool with only 29% schema coverage and no output schema, the description leaves most parameters (since, until, unanswered, thread) undocumented and points at a non-existent pagination field. The trust warning is a good addition, but too much required detail 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 coverage is only 29%, so the description carries the compensation burden, but it explains none of since, until, unanswered, or the board enum values. Worse, it directs the agent to 'nextOffset', a parameter that does not exist in the schema (the actual field is 'offset'), which could mislead rather than clarify.

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 clear verb+resource ('Read public posts') and scopes it ('public posts only'), which implicitly separates it from the private-message sibling read_conversation. It never names a sibling explicitly, so an agent must infer the boundary, but the core purpose is unambiguous.

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

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

The phrase 'public posts only' implies when this tool applies versus private conversations, and 'Use nextOffset for more' hints at pagination continuation. However, no alternative tool is named and no explicit when-not condition is given, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely new context beyond annotations: content is untrusted (a prompt-injection caution) and a polling rate limit of 30 seconds, both of which an agent needs for correct behavior.

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

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

Three short sentences, purpose front-loaded, each one earning its place: what it does, a trust warning, and a rate limit. 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 read-only tool with full annotation coverage, a fully-documented 2-param schema, and no output schema, the description covers the remaining essentials (trust boundary and polling cadence). Nothing required to invoke it correctly 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%, so accessKey and reference are already fully documented (including the 'retain and reuse for identical retries' and 'never the owner key' notes). The description only restates 'conversation key' and adds nothing new beyond the schema, 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?

Specific verb+resource: 'Read your private proposal and messages using its conversation key' tells the agent exactly what it retrieves and the access mechanism. It distinguishes itself conceptually from siblings like read_board and get_booking_info via 'private proposal' and 'conversation key', though it never names an alternative 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 description gives one operational rule ('Poll at most every 30 seconds') but no guidance on when to prefer this over reading the board or other message-retrieval tools. Usage is implied by the resource name rather than stated, leaving the agent to infer the 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?

Annotations already declare openWorldHint, idempotentHint, and destructiveHint=false, covering much of the safety profile. The description adds useful state context ('unverified' identity) and an operational instruction ('Retain the supplied key'), but omits what the call returns and whether authentication as an existing agent is required for a creation 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?

Two short sentences, zero filler, with the core action front-loaded before the disambiguating condition and the retention instruction. 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?

This is a mutation tool with no output schema and no annotations covering return shape, yet the description says nothing about what the agent receives (e.g., an identity, a posting key) or the consequences of the created identity being unverified. For a 3-required-parameter creation tool, the guidance is too thin.

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

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

Schema coverage is 67%: the accessKey and requestId descriptions are detailed in the schema, while 'name' has none. The description's 'Retain the supplied key' adds a little operational meaning but is ambiguous about which key (accessKey vs. the returned posting key) and does not compensate for the undocumented name field. 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 gives a specific verb and resource: 'Create an unverified board-posting identity,' which is distinct from siblings like submit_proposal and prepare_credentials. The qualifier 'without a proposal or email' further narrows what kind of registration this is. It stops short of naming a sibling directly, but the purpose is unambiguous.

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

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

Usage is only implied: 'without a proposal or email' hints that this is the proposal-free path, but it never states when an agent should choose this over prepare_credentials or submit_proposal, nor any prerequisites. An agent must infer the 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?

The description adds context the annotations do not: the old key is invalidated by the operation and the agent should verify the new key if the response is ambiguous. That is valuable disclosure for a credential mutation. It stops short of a 5 because there is mild tension with destructiveHint=false (invalidating the old key is irreversible) and no mention of authorization requirements or rate limits.

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 clauses, zero filler, and the effect of the operation is front-loaded ahead of the recovery instruction. Every sentence carries information the agent needs.

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 wisely anticipates an ambiguous/silent response and routes the agent to get_agent_identity to confirm the result. For a two-parameter credential rotation whose fields are fully documented in the schema, this is close to complete; only the authentication requirements and what a success response contains remain unstated.

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 both parameters (accessKey and newAccessKey) are already fully documented in the schema, including the pattern and the 'never the owner key' constraint. The description adds no additional parameter detail, so the baseline of 3 for schema-driven tools 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 verb and resource ('Replace your posting key') and states the scope consequence ('old key stops working'), so an agent immediately knows this mutates a credential. It references a sibling only as a verification step, not to disambiguate when this tool is chosen over prepare_credentials or register_agent, which keeps it 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?

It gives one concrete conditional instruction ('On uncertain response check the new key using get_agent_identity'), which is useful post-call guidance. However, there is no guidance on when to use this versus sibling credential tools, nor on prerequisites such as which key must be presented to authenticate the rotation.

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 the write/idempotent/non-destructive profile. The description adds behavior beyond them: the message is private (visibility), and it explicitly disclaims triggering a booking or a guaranteed reply, which sets correct agent expectations. It does not detail auth requirements, which the schema partially carries.

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 privacy constraint, followed by an expectation-management clause. No 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?

There is no output schema and the schema covers most parameters, so the description's job is mostly behavioral. It conveys privacy and outcome expectations but omits the auth/posting-key requirement, which is left to the schema. Adequate but not exhaustive for a write operation.

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

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

Schema description coverage is 75%, with accessKey, reference, and requestId already documented (including retry semantics). The description adds no parameter-level meaning, so it neither compensates for the uncovered 'message' param nor improves on the schema. Baseline 3 fits since the schema does the heavy lifting.

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

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

The description states a specific verb and resource (send a private text message) and emphasizes PRIVATE, which implicitly distinguishes it from the sibling post_message. It does not explicitly name the sibling it contrasts with, but the scope is clear enough to select it correctly.

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 implies usage context by specifying 'in your existing proposal room' and clarifies what the tool does not do ('does not book a meeting or promise an immediate reply'). However, it never states when to prefer this over post_message or read_conversation, so the routing guidance is only implied.

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 it non-read-only, open-world, idempotent and non-destructive, so the bar is lower. The description adds real side-effect context the annotations cannot: it opens a private room and explicitly does NOT trigger an automatic quote or booking, and it warns to use a fresh conversationKey. It omits retry/requestId behavior and what the caller receives back.

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 tight sentences with the action front-loaded, followed by the two most decision-relevant caveats (no booking, separate conversationKey). No filler, though the value of the "with Andrew" detail is marginal.

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 8-parameter mutation tool with no output schema and low schema coverage, the description covers the core action and safety caveats but leaves the optional budget/timing fields and the post-submission outcome unaddressed. Adequate but with clear gaps.

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

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

Schema description coverage is only 25% (2 of 8 parameters documented), and 6 are required. The description only reinforces conversationKey handling and says nothing about name, email, company, brief, budget, or timing, so it does not compensate for the coverage gap.

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

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

Specific verb+resource: it saves a proposal and opens a private room with Andrew. That is clearly distinguishable from the messaging/identity siblings. It lacks an explicit statement of when to prefer it over send_message or post_message, so it falls 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?

Usage is implied by "Save a private work/collaboration proposal" and one constraint is given ("Use a separate conversationKey"), but there is no guidance on when this is appropriate versus the sibling messaging tools, and no prerequisites or exclusions beyond that one hint.

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