Send documents for legally binding e-signature and manage the reusable templates behind them.
Scored across 12 tools
Each tool pairs a distinct resource (contract/template) with a distinct action (create, get, list, update, cancel, send, archive, upload). No two tools overlap in purpose; contract_update vs contract_send are clearly separated by draft vs send semantics.
Every tool follows the same resource_action snake_case pattern (contract_*, template_*), with no camelCase, vague verbs, or convention mixing.
12 tools split evenly across two related resources is well-scoped, and each tool covers a needed operation without redundancy.
Core contract lifecycle (create, get, list, update, send, cancel) and template lifecycle (create, get, list, update, archive, upload) are covered, with cancel/archive standing in for delete. Minor gaps remain around signer-level operations and no hard deletion, but no significant dead ends.
Cancel a draft or sent contract. Only draft and sent contracts can be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
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 reveals the status restriction but does not explain consequences of cancellation, whether it is reversible, required permissions, or what happens to a sent contract after cancellation.
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 core action. The second sentence restates the first restriction, introducing slight redundancy, but overall there is no wasted or 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 a simple one-parameter cancellation tool, the description provides the essential eligibility condition. However, with no annotations and no output schema, it is missing details about return behavior, side effects, and the contract_id format, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain contract_id or the expected pattern. The parameter name and context imply what it refers to, but the description fails to compensate for the missing schema-level explanation of 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 ('Cancel') with a clear resource ('contract') and constrains the action to draft or sent contracts. This clearly distinguishes it from siblings like contract_create, contract_send, and contract_update.
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 an explicit eligibility boundary: only draft and sent contracts can be cancelled. This gives the agent a clear when-to-use condition, though it does not explicitly name alternative tools for other statuses, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new contract from a template or with custom content. Requires at least one signer. The content must contain at least one signature placeholder (for example {{signature}}); with more than one signer, give each signer their own signature placeholder and assign it via signer_fields (for example {{signature_buyer}} and {{signature_seller}}).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | No | ||
| signers | Yes | ||
| test_mode | No | ||
| variables | No | ||
| template_id | No | ||
| expires_in_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior. It discloses important validation behavior: at least one signer and one signature placeholder, and how multi-signer placeholders must be assigned via signer_fields. It does not state whether the contract is created as a draft, whether signers are notified, or what the return payload looks like.
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 focused sentences, front-loading the primary action and then adding prerequisites and placeholder mechanics. Each sentence carries necessary information, with examples that clarify without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, nested signers, no annotations, and no output schema, the description covers the most error-prone aspects (signer requirements, placeholders) but omits the return value, the mutual exclusivity/requirement between content and template_id, and the effect of variables/test_mode. It is adequate but has 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 coverage is 0%, and the description adds crucial meaning beyond the schema: it explains the template vs custom content modes, ties content to signature placeholders, and maps signer_fields to per-signer placeholders with concrete examples. However, it says nothing about variables, test_mode, expires_in_days, or the output/returned contract, so compensation is incomplete.
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 'Create a new contract from a template or with custom content', giving a specific action and resource, and clearly scopes the two creation modes. It does not explicitly name sibling tools such as contract_send or contract_update, so the agent must infer differentiation from the action verb alone.
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 supplies preconditions ('Requires at least one signer') and content requirements (signature placeholders, signer_fields assignment), which guide valid calls. However, it never states when to prefer this tool over contract_send or contract_update, nor what should not be done; usage is only implied by the verb 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific contract by ID, including signers, their status, and whether their signing request email was delivered (email_delivery).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the response shape (signers, their status, email delivery state), which implies a read-only operation, but says nothing about permissions, error behavior for missing IDs, or whether data is cached/live.
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 identifies the action, the keying parameter, and the payload contents with zero filler. Nothing is redundant with the schema or title.
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 read tool with no output schema, the description covers the essential return content an agent would want to know. Only minor gaps remain around failure modes and required permissions.
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 0% and the pattern constraint on 'id' is undocumented, so the description must compensate. It does clarify that the id identifies a specific contract, but adds no format, source, or constraint details beyond that.
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 (Get) and resource (a specific contract by ID), and enumerates the notable payload contents (signers, statuses, email_delivery). It is clearly distinguishable from contract_list by its singular, ID-based scope, though it does not explicitly name 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 'by ID' implies you must already hold a contract ID (e.g., from contract_list), which is useful implicit guidance. However, there is no explicit when-to-use statement, no alternative named, and no note on what happens if the ID is unknown or inaccessible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all contracts in the organization with their status.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'List all contracts', which implies a read operation, but offers no details about whether the status parameter filters results, no pagination or ordering info, and no statement about 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?
A single concise sentence that states the tool's purpose without unnecessary words. It is front-loaded, though the phrase 'with their status' is somewhat ambiguous and could have been made clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, this is borderline, but the missing explanation of the status parameter is a critical gap. An agent may not realize that providing status filters the list. There is also no mention of return shape or behavior when no status is provided.
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 description adds no semantic meaning to the single 'status' parameter. 'With their status' might refer to the output, not to an optional filter. Schema coverage is 0%, and while the enum values provide allowed inputs, the description does not explain how or when to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('all contracts'), and mentions status as a relevant field. It clearly differs from mutation siblings like contract_create and contract_cancel, though it does not clarify that status is a filter rather than simply an output field.
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 verb 'List' implies this tool is for viewing contracts, and sibling names suggest other operations. However, there is no explicit guidance on when to use contract_list versus contract_get (e.g., multiple vs single), nor any mention that it is read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a draft contract to its signers, or resend a sent one. Charges the organization's balance for each send or resend (test-mode contracts are never charged and their emails go to the organization instead of the signers). A resend only re-emails signers who have not signed yet; signatures already collected are kept. Contracts past their expiration date cannot be sent.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses billing behavior (organization balance charged per send/resend), test-mode exemptions (no charge, emails rerouted to the organization), resend side effects (only unsigned signers re-emailed, existing signatures preserved), and a hard precondition (expired contracts cannot be sent). This is exactly the mutation-level context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying distinct operational value, with the primary action and cost model front-loaded. Dense but not padded; no sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation with no annotations and no output schema, the description covers preconditions, side effects, and billing adequately. It omits return shape and idempotency/double-charge guidance, which output schema absence makes less critical but still a minor 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?
One parameter (contract_id) with 0% schema description coverage, but the schema supplies a format pattern and the name is self-explanatory. The description implies the ID may reference either a draft or a sent contract, adding a little semantics, but no format or sourcing guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (send/resend a contract) and covers both operating modes — draft vs. already-sent — up front. It does not explicitly name a sibling or contrast itself with contract_update/contract_cancel, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditions for use: valid on draft or already-sent contracts, invalid past the expiration date, and the resend path is scoped to unsigned signers. No explicit alternatives are named for related actions, but the trigger conditions are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a draft contract's details or signers. Only draft contracts can be updated.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| content | No | ||
| signers | No | ||
| contract_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it does add a useful constraint: only draft contracts can be updated. However, it does not explain whether updates are partial or full replacements, how non-draft contracts are rejected, what permissions are needed, or what the response 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?
Two short sentences with the action front-loaded and no filler. The second sentence reinforces the draft-only constraint and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters including a nested signers array, no output schema, and no annotations, this description leaves significant gaps: parameter semantics, update semantics, failure conditions for non-draft contracts, and return behavior are all unaddressed. It is minimally adequate for selecting the tool but not for reliably invoking it in complex 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 description coverage is 0%, and the description only loosely maps to parameters via 'details or signers'. It does not define contract_id format, the structure of signers, or that name, content, and signers are optional, so the schema's lack of parameter docs is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Update') and a clear resource ('a draft contract's details or signers'), so its purpose is immediately obvious. The draft-only scope also distinguishes it from sibling lifecycle tools like contract_create, contract_send, and contract_cancel.
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 sentence 'Only draft contracts can be updated' gives a clear eligibility condition for using this tool. It does not explicitly name alternatives or say what to do for non-draft contracts, but the constraint and sibling names make the intended usage boundary evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Soft delete a template by marking it as archived.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses that the operation is a soft delete achieved by marking the template as archived, which is important behavior not conveyed by the tool name alone. However, with no annotations, it does not mention whether this is reversible, what effects it has on list/retrieval operations, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core behavior. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation tool, the description is adequate but not complete. It clarifies the soft-delete semantics but omits guidance on reversibility, side effects on listing or retrieval, and when to choose this over other template operations.
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 0% and the description does not explain the 'id' parameter beyond the obvious implication that it identifies the template to archive. The description adds no details about the id format or where to find it, so it fails to compensate for the missing schema documentation.
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 operation: 'soft delete a template by marking it as archived.' The verb 'soft delete' and resource 'template' are specific, and this distinguishes the tool from siblings like template_update or contract_cancel, which do different things.
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 does not provide any guidance on when to use this tool versus alternatives like template_update or template_list. 'Soft delete' implies a use case, but there is no explicit context, exclusion, or alternative mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new blank template with a name and optional markdown content.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the initial state ('blank') and that content is optional, which is useful. However, it does not mention uniqueness constraints, default behavior, error conditions, or what the result of creation is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the core purpose and conveys all the essential information it includes efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter create tool, the description is adequate but not complete. It lacks explicit differentiation from template_upload, behavioral details like idempotency or uniqueness, and any indication of the return value or post-creation state.
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 0%, but the description does add meaning by identifying 'name' and 'markdown content' as the inputs and noting that content is optional. It still does not explain name requirements, content formatting details, or the relationship between the parameters beyond what the schema structure implies.
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, 'create', and a specific resource, 'template', and clarifies it is a 'blank' template with 'name and optional markdown content.' This clearly distinguishes the action from sibling tools like template_update or template_upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new blank template, especially via the word 'blank' which contrasts with template_upload. However, it does not explicitly state when to use this tool instead of template_upload or template_update, nor does it mention any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific template by ID, including its content and field definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. 'Get' clearly implies a read-only, idempotent operation, and specifying that it returns content and field definitions adds some transparency. However, it does not disclose error behavior, permissions required, or whether the template includes additional metadata beyond content and fields.
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, tight sentence with no filler. The verb and resource are front-loaded, and the inclusion of 'content and field definitions' provides value without adding length.
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 single-ID getter with one parameter, the description is minimally adequate: it states what the tool does and what the response covers. Yet without annotations or an output schema, it omits key context such as the ID format restrictions, not-found behavior, and relationship to sibling template tools, making it less complete than it could be.
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 0%, so the description must compensate for the lone 'id' parameter. Saying 'by ID' merely restates the parameter name and does not explain the required pattern (^[cC][^\s-]{8,}$) or provide guidance on how to obtain or format the ID. This leaves a meaningful gap for an agent trying to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') on a specific resource ('a specific template by ID') and even describes what is included in the result ('content and field definitions'). It distinguishes from listing or mutating templates, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need a single template by ID and want its content or field definitions. However, it provides no explicit guidance on when not to use it or how it differs from template_list, template_create, or template_update, leaving the routing decision mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all templates in the organization. Returns template IDs, names, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that this is a non-destructive listing operation and specifies the returned data shape (IDs, names, timestamps). It does not mention pagination or ordering, but for this simple tool the description provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and resource, followed by the return-value summary. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description fully covers what it does, what it returns, and the organizational scope. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter detail required. The description's 'all templates' wording reinforces that no filtering is possible, which is useful 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 states a specific action ('List all templates') with a clear resource and organizational scope. It also names the returned fields, which distinguishes it from siblings like template_get that would retrieve a single template.
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 'List all templates in the organization' clearly communicates the intended use case: when the agent needs a broad inventory of templates. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a zero-parameter list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing template's name, content, or field definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| fields | No | ||
| content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool updates a template but does not disclose whether updates are partial or full replacement, whether fields can be cleared, whether any destructive consequences occur, permission requirements, or what happens to existing 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?
A single concise sentence that front-loads the action and resource, then lists the updateable fields without any filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a 0% schema description coverage, the description is too sparse for an agent to invoke the tool safely. It does not mention the required id, partial-update behavior, or any side effects, and the presence of sibling tools like template_archive and template_upload does not compensate for this missing 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?
The description names three of the four schema properties (name, content, and field definitions corresponding to fields), which adds some meaning beyond the bare property names. However, it omits the required id parameter entirely and does not explain value constraints such as the id pattern, minLength, or the completedBy enum, leaving significant gaps given 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and resource ('existing template'), and enumerates the specific attributes that can be changed: name, content, or field definitions. This distinguishes it from sibling tools like template_create, template_get, and template_archive without requiring any further investigation.
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 'existing template' implies this tool is for modifying an already-created template rather than creating or listing one. However, the description gives no explicit when-to-use guidance, no exclusions, and does not name alternative tools for different scenarios, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload and convert a Word .docx file to a template. File must be base64 encoded. Legacy .doc files are not supported; save them as .docx first.
| Name | Required | Description | Default |
|---|---|---|---|
| fileData | Yes | ||
| filename | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the input-format contract (base64) and a hard format restriction (no legacy .doc). It does not cover auth requirements, file-size limits, overwrite/duplicate-name behavior, or what the conversion produces, which are meaningful gaps for an unannotated mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, then the encoding requirement, then the format caveat. No filler and every sentence carries an actionable constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter ingestion tool with no annotations and no output schema, the description covers the critical input pitfalls (.docx only, base64) but omits filename semantics and any indication of what is returned (e.g., a template identifier needed for follow-up calls), which matters since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the schema itself documents neither parameter. The description compensates for fileData by specifying base64 encoding, but says nothing about filename (extension handling, uniqueness, whether it drives the template name), leaving one of two parameters semantically underspecified.
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 pair (upload and convert) plus the resource and source format (.docx to a template), so an agent immediately knows this ingests a document rather than authoring one. It implicitly separates itself from template_create/template_update, though it never names 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?
The preconditions for input are clear (base64 encoding required, .docx only, .doc rejected), which is genuine usage guidance. However, it gives no comparative guidance on when to call template_upload versus template_create or template_update, leaving the agent to infer that this is the file-ingestion path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
contract_create1 field changedInput schema / properties / test_modeAdded value: +{
+ "default": false,
+ "type": "boolean"
+}contract_cancelcontract_createcontract_getcontract_listcontract_sendcontract_updatetemplate_archivetemplate_createtemplate_gettemplate_listtemplate_updatetemplate_uploadSend documents for e-signature from templates, track status, remind signers, get signed PDFs.
Send agreements for e-signing, use templates, track signatures, send reminders, get signed documents
E-signatures: send, track, remind, void and download envelopes; templates and reports.
Read and send documents for signature — templates, recipients, fields and folders.
Add one secure layer between your agents and this server.
