Legally binding e-signature for agents. Build a contract from a reusable Markdown template with Handlebars variables, fill them in, send it to signers, and track viewing and signing through to completion. Twelve tools across templates and contracts. Requires an APISign API key in the x-api-key header.
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 | ||
| 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 provided, the description carries the behavioral burden. It discloses a non-obvious validation rule: content must contain signature placeholders and each signer needs a unique placeholder via signer_fields. However, it does not explain whether the contract is sent immediately, what the return value is, or other 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?
Two sentences with the purpose front-loaded and the critical placeholder rule following. The phrase 'Requires at least one signer' is redundant with the schema's minItems:1, but overall the description is appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the central creation requirements and the most important validation rule. It leaves gaps: no return value described (and no output schema), and several parameters (variables, expires_in_days, name) are undocumented, which is significant for a 6-parameter tool with nested objects.
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. It adds meaning for content vs template_id and explains signer_fields usage with example placeholders. But it does not clarify name, variables, expires_in_days, or the full structure of the signer objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a new contract from a template or with custom content.' This clearly differentiates it from sibling tools like contract_update, contract_send, and contract_cancel, and the two creation modes are 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?
Provides clear context for when to use this tool: creating a new contract, either from a template or with custom content. It does not explicitly name alternative tools or exclusion scenarios, but the creation intent is unambiguous.
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 and their status.
| 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 behavioral burden. The verb 'Get' implies a safe read operation with no side effects, and the description discloses some returned content. But it does not address permissions, errors, or any other behavioral traits, which is a modest gap for a one-parameter read 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?
A single, front-loaded sentence with no filler. Every word contributes: 'Get', 'specific contract', 'by ID', and the signers/status detail all add distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with exactly one required parameter and no output schema, the description is largely sufficient. It explains what the tool returns at a high level. Minor omissions like error behavior or exact response structure are not critical for a basic get-by-ID tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only repeats that the tool works 'by ID.' The input schema's id pattern (^[cC][^\s-]{8,}$) is restrictive and potentially confusing, yet the description does not clarify what constitutes a valid contract ID or how the id is used beyond the obvious.
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 specific resource ('specific contract by ID') and adds meaningful detail about the returned data ('including signers and their status'). This clearly distinguishes the tool from siblings like contract_list, contract_create, 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 phrase 'specific contract by ID' implies this is the tool to use when you already have a contract identifier and need one contract, rather than a list. However, it does not explicitly state exclusions or name alternative tools, leaving some usage inference to the agent.
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 contract to signers for signing. Charges the organization's balance and sends email notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses two significant traits: 'Charges the organization's balance' (financial impact) and 'sends email notifications' (side effect). This goes beyond the name and alerts the agent to consequential behavior, though it does not mention reversibility or status changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence with no filler. The core action is front-loaded, and the key side effects are stated immediately. Every word adds value, making it easy to read and parse.
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 tool with no output schema, the description provides the primary purpose and two important behavioral consequences. It omits potential prerequisites (e.g., contract must have signers, what state it must be in) and what happens on failure, but these are not critical for basic invocation given the schema already specifies the required parameter.
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 only one parameter, contract_id, with a pattern but no description, and schema description coverage is 0%. The tool description does not mention or explain the parameter at all, so it fails to compensate for the lack of schema description. The parameter name and pattern provide some intrinsic clues, but the description adds no parameter-level meaning.
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 contract to signers for signing.' This clearly distinguishes it from sibling tools like contract_create, contract_update, and contract_cancel, which have different actions. No ambiguity remains about what operation this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: a contract is ready to be sent for signing. It names the purpose ('for signing') and important side effects, giving the agent context for when to invoke it. However, it does not explicitly mention when not to use it or name alternative tools for other contract stages.
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 DOCX/DOC file to a template. File must be base64 encoded.
| Name | Required | Description | Default |
|---|---|---|---|
| fileData | Yes | ||
| filename | 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 discloses only that files must be base64 encoded and that upload triggers conversion, but omits side effects, output/return behavior, and success/failure semantics, making agent expectations underspecified.
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 contain the core purpose and a key constraint with no filler or repetition. The information is front-loaded and easily parsed.
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?
Even though the tool is simple, the absence of an output schema and annotations means the description should cover return value, error conditions, and any side effects. None are mentioned, and the relationship to template_create is unclear, so an agent cannot fully anticipate the call's consequences.
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 has zero description coverage (0%), so the description must compensate. It adds a critical constraint for fileData ('File must be base64 encoded') but says nothing about filename, its required format, or how it relates to the resulting template, leaving one of two parameters largely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Upload and convert') and a resource ('a template'), and specifies accepted input types (DOCX/DOC). However, it does not explicitly distinguish itself from sibling template_create, which also involves creating a template, so differentiation is left to inference.
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 guidance on when to choose this tool over template_create or template_update, and no exclusions or prerequisites beyond the base64 requirement. Usage context must be inferred from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a unique resource-action pair: contract operations are clearly separated from template operations, and actions like create, get, list, update, send, cancel, archive, and upload are distinct. There is no meaningful overlap or ambiguity between the tool purposes.
Tool names follow a consistent noun_verb pattern: contract_create, contract_list, template_get, template_upload, etc. This makes the API surface predictable and easy for an agent to navigate.
Twelve tools is well-scoped for a document-signing server covering both contracts and templates. Each tool serves a clear lifecycle purpose, and the count feels neither bloated nor thin.
The toolset covers the core contract lifecycle (create, update, send, cancel, get, list) and template lifecycle (create, update, archive, upload, get, list). Minor gaps exist, such as no way to permanently delete a contract, restore an archived template, or download signed contract documents, but these are not critical for the main workflows.