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

With no annotations, the description carries the full burden of disclosing side effects. It does mention the invitation email, which is useful behavioral information. However, it omits that this is a mutating operation on the template's collaborator list, whether the access persists, what permissions are needed, or how the action can be reversed.

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 short and front-loaded with the primary action, followed by the conditional email behavior. It is efficient with no fluff, though the double period and 'a HTTPS' grammar issue make the text feel slightly unpolished.

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 no annotation coverage, so the description should explain what the tool returns, but it never states whether the generated HTTPS link is the return value. It also does not cover permission requirements, reversibility, or how this affects existing collaborators. For a mutation tool with optional email side effects, this is a significant completeness 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 schema already describes name and email, and the description mostly restates the email-to-invitation behavior. It adds some context by clarifying that the tool creates an editing link for the template, which helps explain the purpose of template_id. It does not add meaningful detail about name or any parameter constraints.

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

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

The description gives a specific outcome: creating an HTTPS link for editing a contract template and conditionally sending an invitation email. The action is concrete enough for an agent to understand the tool's basic function. However, it never explicitly says it 'adds a collaborator' to a template, so part of the core meaning relies on the tool name rather than the description.

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

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

There is no guidance on when to choose this tool over alternatives such as remove_template_collaborator or list_template_collaborators. The description only explains what the tool does, leaving the agent to infer usage context from the tool name and sibling list. No exclusions or alternative routing are provided.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden, and it does add meaningful traits: the contract can be draft or instantly sent, signature fields are automatically handled and must not be added manually, and placeholder/signer field behavior is explained. However, it does not disclose side effects such as signature-request emails being sent, authentication/ownership requirements, or fee and reminder behavior, leaving an agent with important unknown consequences for a mutating 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?

The description is three sentences long and every sentence earns its place: purpose, mode options, automatic signature-field handling, and placeholder/signer field behavior. It is appropriately front-loaded with 'Creates a new contract' and wastes no words on irrelevant 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 an 18-parameter tool with nested objects, no annotations, and no output schema, the high-level description is somewhat thin. It does not integrate or highlight key parameter relationships such as template_id being required unless document_elements is provided, the meaning of contract_source/mcp_query, or how save_as_draft affects the workflow. The schema fills most gaps, but the agent would still need to wade through a very large schema without a compact operational overview.

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 already documents every parameter in detail. The description adds some cross-cutting context about placeholders and signer fields, but it does not explain specific parameter mechanics such as template_id vs document_elements or save_as_draft behavior beyond what the schema already 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?

The description opens with the specific action 'Creates a new contract' and immediately clarifies the main modes: a draft the user customize/send or an instantly sent contract. It also distnguishes this from sibling resource-level tools like create_template by focusing on the contract entity and its signing workflow. The mention of automatic signature field handling further sharpens what is unique about this tool.

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

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

The description provides no explicit when-to-use guidance or exclusions relative to sibling tools such as create_template, query_contract, or withdraw_contract. It implies usage by saying 'Creates a new contract,' but it does not explain when this tool should be used instead of a template-oriented flow or when draft vs. instant sending is appropriate at the decision 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 burden of behavioral disclosure. It only says 'Creates', with no mention of side effects, generated IDs, label inheritance, placeholders, signer field behavior, or reversibility. The schema contains some behavioral notes, but the top-level description itself is minimal.

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 with no redundancy or filler. It is front-loaded with the core action, though it is too terse to convey broader behavioral context.

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

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

Given the tool's complexity (rich document_elements schema, no annotations, no output schema, and no sibling differentation), the description is incomplete. It does not describe what the tool returns, how templates are later used by contracts, or any operation-level side effects. The schema covers parameters but not the surrounding workflow context.

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 (title, labels, document_elements) in detail. The description adds no parameter-specific meaning beyond the schema, 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?

The description states a specific verb ('Creates') and resource ('reusable contract template') and gives the purpose ('for contracts to be based on'). It clearly distinguishes the operation from contract creation or template modification, though it does not explicitly contrast with 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 phrase 'for contracts to be based on' implies the intended use case: creating a template to be reused by future contracts. However, it gives no explicit guidance on when to choose this over alternatives like create_contract or update_template, and no exclusions.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It correctly indicates destructive scope and the restriction to test/draft states, but does not state permanence, permissions, or what happens if the condition is not met.

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 no filler. The action is front-loaded and the eligibility condition follows immediately, making the description easy to process.

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

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

For a single-parameter delete tool without annotations or output schema, this description covers the core object and the key precondition. It leaves out only secondary details such as error handling or side effects, which are less critical for simple deletion.

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 fully describes contract_id as 'GUID of the contract to be deleted', so the tool description adds no parameter-level meaning. With 100% schema coverage, 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 names a specific action ('Deletes') and resource ('a contract'), and adds a scope restriction (only test or draft contracts). However, it does not explicitly distinguish this from the sibling withdraw_contract, so it is clear but not fully differentiated.

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 eligibility condition ('only be deleted if it's a test contract or a draft contract') gives concrete guidance on when this tool can be applied. It stops short of naming an alternative for non-draft/test contracts, but the context is clear enough for selection.

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. 'Deletes' communicates a destructive action, but it does not mention irreversibility, cascading effects, permissions, or what happens after deletion. Additional behavioral context is missing.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the action and resource directly and is appropriately concise for a simple one-parameter 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?

For a simple one-parameter deletion tool, the description plus schema provides enough to invoke it. However, it lacks behavioral details such as deletion permanence, potential restrictions, and side effects, so it is adequate but not fully complete.

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

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

The input schema already fully documents template_id as a required GUID, with 100% schema description coverage. The description adds no extra semantic detail, but none is needed beyond what the schema provides, so a baseline score 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 'Deletes a contract template.' clearly identifies the action (delete) and the resource (contract template). This distinguishes it from siblings like delete_contract, which targets contracts rather than templates.

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 the goal is to remove a contract template. However, it gives no explicit context about prerequisites, exclusions, or how it compares to alternatives like delete_contract or withdraw_contract.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It does mention the 100-item limit and recency, but it does not define what 'latest' means, what fields are included in 'details,' or whether the operation is read-only.

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

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

The description is a single sentence with no filler, and the key scope ('latest 100 contracts') is front-loaded. The minor typo 'the the' does not meaningfully reduce conciseness or structural quality.

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 listing tool with no output schema, this description conveys the core behavior but leaves ambiguity about ordering semantics and the exact shape of the returned contract details. It is adequate for basic selection but not fully complete.

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

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

The input schema has zero parameters, so there is nothing for the description to clarify; the baseline for 0-parameter tools is 4. The description adds no parameter details, but none are needed given the empty 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 states the verb ('Returns') and the resource/scope ('details of the latest 100 contracts'), making the basic purpose understandable. It does not explicitly differentiate from query_contract, but the 'latest 100 contracts' framing is specific enough to distinguish it from template-related siblings.

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

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

No guidance is provided about when to use this tool versus alternatives such as query_contract or create_contract. There are no exclusions, prerequisites, or selection criteria, so the agent must infer usage solely from the name and minimal 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, the description carries the burden of indicating that this is a read operation; 'Returns' does suggest that, and the listed fields preview the response. However, it does not disclose permissions, error behavior, pagination, or behavior for an invalid template_id.

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 states the operation and the most useful output fields with no filler, repetition, or unnecessary 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 one-parameter list operation with no output schema, the description is largely complete: it identifies the input template and the returned collaborator fields. It lacks only minor semantics such as pagination or error behavior, which are less critical for a simple list tool.

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

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

The schema provides only a required string template_id with 0% coverage, so the description must compensate. It indirectly clarifies that the parameter identifies the template whose collaborators are listed, but it does not explicitly describe the parameter's meaning, format, or constraints.

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

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

The description uses a specific verb ('Returns the list') and resource ('template collaborators'), and it names the key fields included. This makes the tool easy to distinguish from siblings like add_template_collaborator and remove_template_collaborator.

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 retrieving collaborators on an existing template, but it does not explicitly state when to use it over alternatives or mention exclusions. The use case is reasonably clear for a simple list operation, but no routing 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 present, the description carries the full burden of behavioral disclosure. It only says 'lists,' which weakly implies a read-only operation, but it does not disclose pagination, authentication requirements, returned fields, or whether all templates are returned.

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 short sentence with no wasted words and starts with the verb. It is concise, though its brevity makes it feel minimal and somewhat redundant with 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?

There is no output schema, so the description is the only information an agent has about the return value or side effects. 'Lists the templates' is too sparse to confirm the result type, the fields returned, or whether any filtering occurs. For a zero-parameter tool it may be usable, but it is not complete enough to reliably distinguish behavior from sibling list/query tools.

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

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

The tool has zero parameters and the input schema is empty, so the baseline for this dimension is 4. There are no parameter semantics for the description to add or 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?

The description uses a specific verb ('Lists') and a concrete resource ('templates'), so the basic operation is clear. It does not explicitly distinguish itself from sibling query_template, and 'the templates' is underspecified, 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 use this tool versus query_template, list_recent_contracts, or list_template_collaborators, and no mention of when not to use it. Usage must be inferred entirely from the name and the single verb.

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 disclose meaningful behavior: optional fields are conditional, signer events are only included for recent contracts, and rate limiting applies. It does not explicitly state that this is a read-only operation or describe error/not-found behavior, which would increase transparency.

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

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

The description is a single dense sentence that packs in the key return fields and important caveats without unnecessary filler. The opening phrase 'contract details' is slightly redundant with the explicit list that follows, but overall it remains compact and readable.

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, the description does a good job listing expected return fields and important conditional behaviors like optional PDF/expiry and signer-event rate limiting. It could be more complete by specifying rate-limit details and what happens for invalid or draft contracts, but for a one-parameter query tool it is largely sufficient.

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 fully documents the single contract_id parameter, including the GUID format and the draft-contract restriction. The description adds no parameter-specific detail, so the baseline score 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 identifies a query/read operation for a single contract and enumerates the returned fields, making the tool's purpose unambiguous. It does not explicitly contrast with list_recent_contracts or query_template, but the resource and verb are still clear.

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

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

The description implies the tool is for retrieving a specific contract's details via contract_id, and the caveat about signer events only for recent contracts provides some context. However, it does not explicitly say when to prefer this over list_recent_contracts or mention the draft-contract exclusion, which lives only in the schema.

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 implies a read operation by saying 'Responds with' and lists output fields, but it does not explicitly state that the tool is read-only or describe error behavior, permissions, or side effects.

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 run-on sentence containing a typo ('int he'). It is front-loaded with 'template details' and lists the returned fields, but the structure is jumbled and could be clearer if broken into a sentence and a list.

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 is responsible for explaining what is returned. It lists most key fields and mentions document_elements content, but it does not clarify the response structure, whether some fields are optional, or what happens for a nonexistent template_id.

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

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

Schema coverage is 100% and the only parameter, template_id, is already described as a GUID of the template. The description does not add parameter-level semantics, but the schema fully documents the parameter, 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 that the tool responds with template details and enumerates specific fields (template_id, title, labels, created_at, placeholders, signers, document_elements), making the resource and output clear. It is distinguishable from siblings like list_templates and query_contract, though 'Responds with' is a weak action verb and the read behavior is only implied by the tool name.

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

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

No guidance is provided about when to use this tool versus list_templates or query_contract. The description only reports what is returned and does not mention exclusions, prerequisites, or alternative routing.

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

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

There are no annotations, so the description carries the full behavioral burden. 'Removes' reveals the core mutation but does not disclose whether the removal is permanent, whether it affects collaborator access elsewhere, or whether any authorization is required. The lack of side-effect or reversibility context leaves the agent under-informed for a destructive 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 short sentence with no filler and the main verb is front-loaded. It loses one point only because the terseness omits a little context that would make the resource unambiguous.

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, has fully documented parameters, and no output schema, so the description does not need to explain return values. However, with no annotations and no mention of permanence or side effects, it is only adequately complete rather than richly specified.

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

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

Schema description coverage is 100% and both parameters have GUID descriptions, so the schema already documents the inputs. The description does not add parameter-level meaning, which fits 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 uses a specific verb ('Removes') with a specific resource ('the template collaborator'), and the sibling set includes add_template_collaborator and list_template_collaborators, so an agent can distinguish this removal operation immediately.

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 states only what the tool does, with no guidance on when to use it, when not to use it, or how it relates to add_template_collaborator/list_template_collaborators. It is not misleading, but an agent gets no decision 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the affected fields and does not state whether the document content is fully replaced or merged, whether the update is reversible, or what the response looks like. For a mutation tool, this is a significant transparency gap.

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

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

The description is a single, concise, front-loaded sentence with no filler or redundant wording. Every part contributes to stating the tool's action and 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?

The tool has a complex document_elements schema, no annotations, and no output schema, yet the description provides no further context. It omits update semantics, target identification, and return behavior, leaving an agent under-informed for a mutation 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 100%, and each parameter already has a meaningful description in the schema. The description only echoes the parameter names without adding new semantic detail, 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?

The description clearly states the verb ('Updates'), the resource ('contract template'), and the affected aspects ('title, labels or the content'). This distinguishes it from sibling tools such as create_template, delete_template, query_template, and list_templates by making its update role explicit.

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 update purpose implies this tool is for modifying an existing template rather than creating or deleting one, matching the sibling set. However, the description gives no explicit guidance on when to prefer this tool over create_template or any other alternative, leaving usage largely 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 present, the description carries the full burden of explaining behavior. It only states the action 'withdraws a sent contract' and gives a state precondition, but does not disclose whether the operation is destructive, reversible, requires permissions, or produces side effects. For a mutation tool, this is a significant transparency gap.

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

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

The description is very concise and front-loaded, with no wasted words. However, it is arguably under-specified rather than efficiently complete, so it does not earn a 5.

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 absence of annotations and output schema, the description is too sparse to fully contextualize a mutating contract operation. It does not clarify the contract lifecycle, what 'withdraw' entails, when it is valid, or how it differs from deletion, leaving an agent without enough context to invoke it confidently.

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

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

Schema description coverage is 100% and the single parameter contract_id is already documented as 'GUID of the contract to be withdrawn.' The description adds little beyond what the schema provides, so the baseline score 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 states the specific verb 'withdraws' and the resource 'sent contract,' which clearly identifies the operation and distinguishes it from generic contract actions. However, it does not explicitly contrast with delete_contract, so some ambiguity remains about whether withdrawal is a deletion or a state transition.

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

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

No guidance is provided about when to use this tool versus alternatives like delete_contract, query_contract, or create_contract. The phrase 'sent contract' implies a precondition, but exclusions, prerequisites, and alternative routing are left entirely to inference.

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