votel-mcp

Official

by votelai

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.1
Disambiguation4/5
Most tools target distinct resources with clear actions. A few pairs like complete_task vs update_task and upload_file vs publish_site could be confused, but descriptions provide enough detail to differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (list_, get_, create_, update_, delete_, add_, remove_, etc.). No style mixing or unpredictable naming.
Tool Count2/5
With 45 tools, the surface is quite heavy. While the server spans multiple domains (websites, CRM, pipelines, tasks), the count exceeds the typical comfortable range and includes some redundant convenience tools like complete_task.
Completeness4/5
The tool set covers most core workflows for websites, contacts, and tasks. Minor gaps exist, such as no update_website or pipeline creation/editing, but these can be worked around or are outside the primary scope.
Average 3.9/5 across 45 of 45 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions the metrics returned but does not state whether the operation is read-only, requires permissions, has rate limits, or how it handles date defaults (which are in the schema). The 'get' verb implies read-only but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a clear statement of function and a useful natural-language example. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with full schema coverage, the description covers purpose and the key output metrics. It does not describe the return format, but no output schema exists, and the metrics are listed. The omission of date-range handling is minor since the schema documents it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters with 100% coverage, including default behaviors for date ranges. The description adds no new meaning beyond the schema, so it meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get traffic analytics for a website' and lists specific metrics (requests, bandwidth, cache hit ratio), making the verb and resource clear. It distinguishes from siblings because no other tool offers analytics, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example 'Show analytics for my website' implies when to use the tool with natural language, but there is no explicit guidance on when to use it versus alternatives or when not to use it. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Move a contact,' which implies a mutation, but does not mention whether it is reversible, what permissions are needed, what happens to the contact's history, or what the response will be. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the main purpose front-loaded. The example is concise and adds a helpful real-world illustration without unnecessary detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple mutation with no output schema and no annotations. The description provides no information about return values, error conditions, prerequisites (e.g., whether the contact must already be in the pipeline), or post-conditions. Given the absence of annotation support, the description is insufficient for a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all three parameters with descriptions, achieving 100% coverage. The description adds no additional meaning about the parameters—it only provides a natural-language example that does not map directly to the schema fields. Baseline 3 is appropriate since the schema already covers the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Move a contact to a different pipeline stage.' It uses a specific verb ('Move') and resource ('contact', 'pipeline stage'), and the example clarifies the intended use. No sibling tool performs the same action, so it is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example provides a concrete use case ('Move John to the Closed Won stage'), implying when to use the tool. However, there is no explicit guidance on when not to use it or how it compares to alternatives like update_contact, which could also modify contact data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'create' without addressing permissions, duplicate folder behavior, path handling, or side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a short, relevant example. It is front-loaded, contains no filler, and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema thoroughly documents all parameters, but the description lacks behavioral context such as what happens on duplicate folder names or what the output is. Since annotations are absent, the description could more fully clarify the operation's effects and success/failure outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 3 parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal value beyond the schema, only illustrating folder_name via the 'images' example, and does not clarify path or site_id semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and clearly identifies the resource: 'a new folder in a website's storage.' This distinguishes it from sibling file operations like upload_file and delete_file. The example 'Create an images folder' reinforces the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example use case ('Create an images folder') but no explicit guidance on when to use this tool versus alternatives. It implies usage for organizing website storage but does not mention exclusions or reference sibling tools like list_files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details beyond the core purpose. It lacks information about default behavior (e.g., returning all tags when no query is given), filtering semantics, sorting, or read-only safety. The description carries the full burden but adds little value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, with the second sentence providing a concrete example. There is zero filler, and every part serves a purpose. It is an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with both parameters documented in the schema, the description is minimally adequate. However, it does not mention return format, default behavior, or the read-only nature of the operation, and without annotations it leaves some gaps for an agent to infer. It could be more complete but is usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both 'limit' (Max results) and 'query' (Substring filter). The description does not add any extra parameter details beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides autocomplete task tag suggestions, with specific examples like 'What tags exist for tasks?' and 'Tags starting with foll'. This distinguishes it from sibling tools such as list_task_statuses and list_task_types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples imply usage contexts (user asking about existing tags or tag prefixes), but the description does not explicitly state when to use this tool versus alternatives or any exclusions. The usage guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action without revealing irreversibility, potential side effects (e.g., SSL certificates, site availability), or error scenarios. For a destructive mutation tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an example, immediately conveying the action in a front-loaded, no-waste format. Every element (the verb, the resource, the example) serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required parameters, no output schema), the description is minimally complete. It explains the core action and gives a use case. However, important context like whether removal is permanent, whether the domain must be verified first, and what happens to the site afterwards is missing. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters (site_id and hostname) with 100% coverage. The description adds only a helpful example that implicitly maps to these fields, but does not enrich the meaning beyond what the schema provides. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a custom domain from a website, with a concrete example that distinguishes it from sibling tools like add_domain and verify_domain. The verb 'remove' and resource 'custom domain' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The meaning of usage is implied by the example phrase, but there is no explicit guidance on when to use this tool versus alternatives such as verify_domain or delete_website. No exclusions or prerequisites are mentioned, making it adequate but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It identifies the destructive action but does not mention whether deletion is permanent, requires special permissions, or affects the live site. This is a significant gap for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus an example, with no redundant text. All information is directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameters with examples. The description explains the core purpose but lacks warnings about permanence or side effects, which are important for a destructive operation. Still, it's adequate for the agent to execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, including an example for file_name and a default for path. The description doesn't add significant detail beyond the schema, but the example does illustrate usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a file') and the resource ('from a website's storage'), differentiating it from sibling tools like delete_website or delete_task. The example reinforces the intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example of use ('Delete old-page.html from my website') but does not explicitly state when to use this tool versus alternatives like purge_cache or delete_website. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does state 'soft-delete', which is a meaningful trait, but it does not mention whether the deletion is reversible, how it affects subtasks, or any permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a short explanatory sentence and an example. Every word earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete operation, the description is adequate. It clearly states soft-delete and gives an example, while the full schema coverage covers parameter details. No output schema exists, but return values are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents task_id as a UUID with 100% coverage. The description's '<id>' placeholder adds no additional meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Soft-delete a task' uses a specific verb and resource, clearly distinguishing it from sibling tools like complete_task or snooze_task. The example further clarifies the intended action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as complete_task or update_task. The example 'Delete task <id>' illustrates invocation syntax but does not explain context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It reveals a backend constraint (no flat status enum) and dependency on list_task_statuses, but does not disclose partial update semantics, error behavior, or how names in the example ('Alice') map to assigned_to_id UUIDs. The example could mislead the agent into passing a name string.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, front-loaded with the core purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 22-param mutation tool with no output schema, no annotations, and low schema coverage. The description covers status handling but omits essential behavioral context such as whether updates are partial, what response is returned, and error handling. The example may be insufficient for resolving named entities to UUIDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 36%, so the description must compensate. It adds meaning for is_completed and status_id, and references list_task_statuses for valid values. However, the majority of the 22 parameters remain undocumented in both schema and description, and the example does not clarify type conversions for assigned_to_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update fields on an existing task' with a specific verb and resource. Explicitly distinguishes from completion toggling by explaining is_completed and status_id, and references list_task_statuses for custom statuses, differentiating from siblings like complete_task and snooze_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on using is_completed for completion and status_id for custom statuses, including the backend limitation of no flat status enum. Includes an example that demonstrates intent. However, it does not explicitly name alternative tools like complete_task or snooze_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal a key side effect: 'Provisions storage and pull zone automatically.' However, it does not mention other consequences such as idempotency, failure behavior, or what happens if the name already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and includes a useful example. It is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple 2-parameter schema and no output schema, and the description explains the creation and provisioning behavior. However, it doesn't describe the return value or post-creation state, which would be helpful for an agent to confirm success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both name and storage_region fully described in the schema. The description adds only a usage example for the name parameter and doesn't contribute additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new website with CDN hosting' and adds specifics about automatic provisioning of storage and pull zone. This distinguishes it from sibling tools like delete_website or publish_site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating websites but does not explicitly state when to use it over alternatives or provide exclusions. The example gives a natural-language trigger, but no explicit 'use this when' guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions optional filtering and gives examples, but it omits important behavioral details like pagination, result ordering, and how filters combine. The example 'Tasks assigned to Alice' is misleading because the parameter assigned_to_id expects a UUID, not a name, which the schema clarifies but the description does not. This lowers transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and highly efficient. The first sentence states the main purpose, and the second provides concrete examples. There is no wasted text, and the structure front-loads the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description covers most filter types but misses limit and project_id. It also does not describe the return format or pagination behavior. For a list tool with no annotations, this is a moderate gap, making it minimally complete but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds natural-language examples that map user intent to filter types (e.g., 'high priority open tasks' to priority and is_completed), but it does not add any new meaning beyond the schema for individual parameters. It also omits limit and project_id entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List tasks with optional filtering by completion, priority, type, assignee, or search term.' This is a specific verb+resource+scope combination. It distinguishes itself from siblings like list_subtasks, list_task_statuses, and list_task_types by naming the core resource and filter dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage examples such as 'Show my tasks' and 'Show high priority open tasks,' which illustrate common scenarios and implied triggers. It clearly indicates when to use the tool (listing/filtering tasks) but does not explicitly mention when not to use it or name alternatives for subtasks or task statuses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the full burden. It only says 'List users in the workspace' without disclosing behavioral traits such as client-side filtering (which is mentioned only in the schema), pagination, or return format. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear front-loaded action statement and a helpful example. Every word serves a purpose, and the em-dash separates the core function from the use case effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, and the description gives a clear purpose and use case. However, it omits what fields are returned (beyond implying IDs) and does not mention the query parameter or any filtering behavior, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single 'query' parameter as a substring filter on name or email (client-side), covering 100% of the parameter meaning. The description adds no additional semantics beyond what is already in the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing users in the workspace, with a specific resource and action. It also distinguishes from sibling tools like list_contacts by specifying the use case of discovering assigned_to_id values for tasks, and provides an example question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('use to discover assigned_to_id values for tasks') and gives an example query. However, it does not explicitly contrast with alternatives or specify when not to use it, though the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It only states 'Clear CDN cache' without mentioning whether the action is irreversible, how long it takes, any permission requirements, or side effects. This is a significant gap for a destructive operation, leaving the agent without critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences and an example. It front-loads the core purpose and provides immediate clarity without any redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, no nested objects), the description is largely adequate for basic invocation. However, it lacks behavioral details (e.g., irreversibility, timing) and does not explain return values, which is important since there is no output schema. It is functional but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters `site_id` and `urls` are already fully documented in the schema. The description's phrase 'Purge everything or specific URLs' aligns with the `urls` parameter but does not add new meaning beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Clear CDN cache for a website.' It specifies the resource (CDN cache) and the action (clear/purge), and distinguishes it from sibling tools like delete_website or publish_site. The example reinforces the purpose, making it obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Purge everything or specific URLs.' It implies the tool is used when a website's cache needs to be cleared, with an option to target specific URLs. However, it does not explicitly mention when not to use it or alternatives, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only restates the operation without revealing side effects, reversibility, permissions, or what happens to the task state. 'Snooze' is vague—does it modify the due date, set a reminder, or change status? This is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an example—every word earns its place. It is front-loaded with the action and resource, and the example reinforces usage without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and 100% schema coverage, the description is mostly adequate. However, as a mutation tool with no output schema or annotations, it lacks critical behavioral context such as whether the task's due date is updated or a reminder is set. This gap prevents full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers both parameters with descriptions, so the baseline is 3. The description adds a natural language example but does not provide additional semantic detail beyond the schema. The example may even suggest accepting relative times like 'tomorrow 9am', which conflicts with the schema's ISO datetime format, but this does not add meaningful parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('snooze') and resource ('task'), plus the outcome ('until a future datetime'). This distinguishes it from sibling tools like complete_task or update_task, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example 'Snooze task <id> until tomorrow 9am' provides clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough that agents can infer when to select it over similar task-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals that file_path is uploaded to Votel storage, but does not disclose what happens if both file_path and url are provided, whether existing attachments are replaced, return values, or permission requirements. This is a significant gap for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences plus an example, with the main action front-loaded. It is concise and without fluff, though the example is somewhat redundant with the preceding sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and both input modes, but lacks details on edge cases, response format, and error handling. Given the tool's simplicity and complete schema, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context by explicitly stating 'either...or' between file_path and url, and clarifying that file_path uploads to Votel storage, which enriches the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Attach a file to a task' which is a specific verb+resource pair. It clearly distinguishes from siblings like upload_file or remove_task_attachment by specifying the task attachment context, and includes the two input modes (local file_path or url) with an example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool via 'Provide either a local file_path... or a pre-hosted url' and includes an example. It does not explicitly exclude alternatives or mention when not to use it, but for this simple attachment tool, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal that setting is_completed=false reopens, adding some transparency about reversibility. However, it does not mention permissions, side effects on subtasks, or error behavior, leaving some gaps for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that state the core action, the optional reopen behavior, and a practical example. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description and schema together cover the essential information. It lacks explicit side-effect or prerequisite details, but for a simple status change it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds an example ('Mark task <id> as done') but does not provide additional meaning beyond what the schema already specifies for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Mark') and resource ('task'), and it distinguishes from siblings by focusing exclusively on completion status, including the reopen capability. The example reinforces the intended usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to mark complete or reopen) but does not explicitly compare it to alternatives like update_task or snooze_task, nor does it state when not to use it. The example gives a usage pattern but not contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'list files and folders' and how to specify the path, but does not mention whether the listing is recursive, whether hidden files are included, what metadata is returned, or whether any permissions are needed. This is a notable gap for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the core purpose. It includes a helpful example without unnecessary verbiage, making it easy for an agent to quickly parse the intended function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, read-only listing tool, the description and schema together provide adequate context. The site_id parameter's reference to list_websites helps the agent act independently. However, the absence of any output format or behavioral caveats keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters fully (site_id and path), including defaults and examples, with 100% coverage. The description's path usage advice largely repeats schema information, adding little new semantic value beyond the context of 'website storage'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists files and folders in a website's storage, which is a specific verb+resource combination. This distinguishes it from sibling tools like upload_file, delete_file, and create_folder, and the example clarifies the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining the root path convention and giving a natural-language example ('Show files in my website'). It does not explicitly mention when not to use it or name alternative tools, but the sibling context and clear purpose make the primary use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of revealing behavioral traits. It describes capabilities ('Supports the full task field set') but does not disclose mutation side effects, return value, permission requirements, or special behaviors like the is_completed follow-up PUT (which appears only in the schema). An agent cannot infer these behaviors from the description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: function, discovery guidance, and an example. Every sentence earns its place and there is no filler. It is front-loaded with the core purpose and immediately orients the agent on required steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 18 parameters, no output schema, and no annotations, the description is helpful but incomplete. It tells the agent how to discover valid IDs but does not explain the return value, error behavior, or edge cases like the is_completed follow-up PUT mechanism. The given complexity calls for more behavioral and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description paraphrases the field set rather than adding new semantic meaning. It highlights the combination of due date, time, and timezone, and maps 'subtask parent' and 'contact link' to schema params, but this is already explicit in the input schema. No additional parameter-level insight is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new task,' which is a specific verb+resource statement. It clearly distinguishes from sibling tools like list_tasks, update_task, and delete_task by using 'create' as the verb and 'task' as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to use sibling tools (list_users, list_projects, list_task_statuses, list_task_types) to discover valid IDs before calling create_task. This is clear when-to-use guidance and also points to alternative tools for prerequisite enumeration. The example sentence reinforces the intended usage pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool aggregates counts by status/priority and is read-only in nature ('summary'), but omits details about return format, auth, or whether subtasks are included. This is minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose, and includes useful examples without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and no output schema, the description sufficiently covers what the tool does and how to invoke it with or without a filter. A bit more detail on the exact output could help, but it is not essential for a stats summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema parameter description already explains the filter, but the description adds value by cross-referencing list_users and clarifying the optional assignee filter. This goes beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a summary of task statistics (counts by status, priority, etc.) for the workspace, distinguishing it from list_tasks or get_task. However, it does not explicitly differentiate from sibling tools like get_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context via examples ('Give me task stats', 'Show task stats for Alice') and mentions the optional filter by assignee. It does not state explicit exclusions or alternatives, but the intended use is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states that the tool checks DNS propagation and SSL status, which implies a read-only operation, but it does not explicitly disclose side-effect freedom, response format, or any prerequisites such as domain ownership. The description is adequate but not rich in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a clarifying example. It front-loads the purpose and avoids repetition of the tool name or schema details. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and full schema coverage, but there is no output schema, so the description should hint at what the tool returns. The example suggests a 'verified' outcome, but the description doesn't describe the result format, potential errors, or behavior during propagation delays. This is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (site_id, hostname) thoroughly, so the baseline is 3. The description adds little beyond the schema—only the example 'example.com' reinforces the hostname parameter. It does not clarify site_id or any parameter relationships beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with a specific verb ('Check') and resource ('DNS propagation and SSL status for a custom domain'). It also gives an example, making the purpose immediately obvious. This distinguishes it from sibling tools like add_domain or remove_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool via the example ('Check if example.com is verified'). It doesn't explicitly state when not to use it or mention alternatives, but the context is unambiguous enough for an AI agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns DNS records to configure, which is a valuable behavioral detail beyond the schema. However, it omits other behavioral aspects like idempotency, duplicate handling, or permission requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, immediately front-loaded with the action. Every word adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the purpose, the return value (DNS records), and provides an example. It lacks minor context like prerequisites for site_id, but overall it is complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented. The description adds no extra meaning about site_id or hostname beyond the schema, but it does not need to; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a custom domain to a website') with a specific verb and resource, and it distinguishes from sibling tools like remove_domain and verify_domain. The example 'Add example.com to my website' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (when adding a custom domain) and hints at the follow-up step (configuring DNS records). However, it does not explicitly mention alternatives or when not to use it, such as referencing verify_domain for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does disclose a validation rule ('Provide at least a name, email, or phone') and makes the write operation obvious with 'Create'. However, it omits details like return value, error behavior, or duplicate handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example. Every sentence adds value, the purpose is front-loaded, and no information is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with full schema coverage, the description is sufficiently complete. It specifies the core purpose, a key validation rule, and an illustrative example. However, it does not clarify the ambiguity between 'name' and 'first_name/last_name' fields, and with no annotations or output schema, a bit more context could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 7 parameters (100% coverage), so the baseline is 3. The description adds the cross-field constraint that at least one of name, email, or phone is required, and provides a concrete example, enriching the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new contact in your CRM' with a specific verb and resource. It unambiguously distinguishes this creation tool from siblings like update_contact, get_contact, and delete_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 creating a new contact) but does not explicitly contrast it with alternatives like update_contact or get_contact. It provides a usage requirement (at least one of name, email, or phone) but no clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention mutational aspects, potential side effects (e.g., effect on existing contacts), uniqueness constraints, reversibility, or permissions. The only behavioral detail is the list of supported types, which is insufficient for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: two sentences and an example. It is front-loaded with the core purpose, then details supported types, and ends with a practical example. Every sentence adds value, and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no nested objects), the description is largely complete. It defines the operation, lists supported types, and offers a clarifying example. It does not mention what the tool returns or any limitations (e.g., duplicate labels), but these are not critical for a basic create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters (label, options, field_type) with 100% coverage, so the baseline is 3. The description adds value through the example, which clarifies how options apply to dropdown fields and demonstrates realistic usage. This lifts the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new custom field') and the target resource ('for contacts'). It also lists the supported field types and provides a concrete example, effectively distinguishing it from sibling tools like create_contact or list_contact_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 a new custom field for contacts is needed) and provides a usage example. It does not explicitly state when not to use it, but the supported types serve as an implicit exclusion. Since there are no direct sibling alternatives, clarity is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the soft-delete behavior, which is important context beyond just 'delete'. It does not address permissions, reversibility details, or side effects on related records, but it gives a reasonable baseline for a simple delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and soft-delete qualifier, followed by a concrete usage example. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one parameter with full schema documentation, and no output schema, the description is nearly complete. It conveys the action, the soft-delete nuance, and usage format. It could mention return values or undo options, but these are not essential for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter is already described as 'The contact ID (UUID)'. The description's example reinforces this but adds no new semantic information beyond what the schema provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a contact from the CRM and explicitly notes it's a soft delete. This distinguishes it from sibling tools like delete_website or create_contact/update_contact, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example 'Delete contact <id>' provides direct usage guidance, and the mention of 'soft delete' sets expectations about what the operation does. However, it does not explicitly contrast with alternatives or state when not to use it, but the simplicity of the tool makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It does disclose the return content (all fields, tags, notes), but it does not mention error behavior (e.g., if contact not found) or explicitly state it is read-only. For a simple get operation this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the core purpose, followed by a useful example. Every word earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations). The description covers the purpose, usage context, and return scope (all fields, tags, notes), which is largely sufficient for an agent. It could mention error handling but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since contact_id is described as 'The contact ID (UUID)'. The description only reinforces this with 'specific contact' and an example, adding no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'specific contact' and details the scope ('including all fields, tags, and notes'). This clearly distinguishes it from sibling tools like list_contacts (which lists many contacts) and get_contact_activity (which focuses on activity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific contact' and the example 'Show me details for contact <id>' make it clear this is for retrieving one contact's full details. It does not explicitly mention alternatives or exclusions, but the context is obvious given sibling names like list_contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It lists activity types but does not disclose how 'recent' is defined, whether the operation is read-only, any pagination behavior, or what the response format looks like. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by relevant examples. No unnecessary words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, all documented), and the description gives sufficient context for selection. It lacks any mention of return value structure, but given the absence of an output schema and the simplicity of the operation, this is a minor omission rather than a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by providing natural-language examples ('John' vs '<id>') for contact_id and summarizing the activity_type enum in its list of activity types. This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent activity for a contact' — a specific verb and resource. It enumerates the activity types (calls, emails, SMS, notes, system events) and distinguishes itself from sibling tools like get_contact and list_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples ('Show recent activity for John' or 'What happened with contact <id>?') provide clear context on when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools, so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that the tool retrieves contacts/leads per pipeline and optionally filters by stage, which is useful. However, it does not mention pagination, ordering, or what happens when no stage is provided—though these are somewhat implied by the optional filter and the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a clear definition followed by two practical examples. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-style tool with no output schema, the description is sufficient to understand the tool's scope and use. The examples make the intended usage concrete, and the schema covers all parameters. A minor gap is the lack of any note about default limit or response shape, but it is not critical for such a straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all three parameters with 100% coverage, so the baseline is 3. The description adds modest value by clarifying the semantics of 'pipeline_id' (a specific pipeline) and 'stage' (optional filter), but it does not add any format details beyond the schema. The example usage reinforces the parameters but does not introduce new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('contacts/leads in a specific pipeline'), clearly distinguishing it from siblings like list_contacts (all contacts) and get_contact (single contact). The optional stage filter is also stated, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need leads/contacts scoped to a specific pipeline, optionally filtered by stage. The examples ('Show leads in my Sales pipeline' / 'Who is in the Negotiation stage?') reinforce the intended use case, though no explicit exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 says 'Get storage credentials for direct file uploads,' which suggests a safe read operation, but it does not disclose details such as credential expiry, scope, or response format. It adds some behavioral context beyond the name but leaves important aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an example, front-loaded with the key action and resource. Every word contributes to understanding the tool's purpose; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately conveys the core purpose and usage context. It omits return value details (e.g., what the credentials look like, expiration) but that is less critical given the simplicity and existing schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a clear description for site_id ('The website ID (UUID)'). The tool description adds no additional parameter semantics beyond what the schema already states, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('storage credentials') with a clear purpose: 'for direct file uploads to a website.' The example reinforces the intent. This distinguishes it from sibling tools like upload_file, which performs the upload rather than retrieving credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for direct file uploads' gives clear context for when to use this tool, implying it is for client-side or direct upload scenarios. However, it does not explicitly mention alternatives (e.g., upload_file) or when not to use it. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. It reveals return content (domains, CDN config, status) but does not confirm read-only nature, error handling, or required permissions, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with a useful example, and contains no filler or redundancy. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with a single required parameter, the description covers purpose, parameter usage via example, and outlines some return fields. It omits error scenarios and a full return structure, but is adequate for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description of 'site_id' as a UUID. The description's example ('website <id>') adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed website info including domains, CDN config, and status. The verb 'Get' plus resource 'website' distinguishes it from sibling tools like 'list_websites' and 'delete_website'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a user needs details of a specific website, with an example query format. However, it does not explicitly mention when to prefer this over 'list_websites' or other alternatives, so usage guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool returns name, email, phone, and lifecycle stage, which is helpful. However, it does not explain pagination behavior, ordering, or whether search is exact or fuzzy, leaving some behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, with the core purpose front-loaded. Every sentence adds value: action, optional filtering, return fields, and concrete user prompts. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with all-optional parameters and no output schema, the description is fairly complete. It covers what the tool does, what it returns, and provides examples. It lacks details on pagination defaults or response structure, but the schema covers parameter behavior, making this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal semantic value by marking search/filtering as optional and providing an example, but it does not enhance understanding of page or limit beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List contacts in your CRM') and distinguishes it from sibling tools like get_contact, create_contact, and delete_contact. It also specifies the scope (search and filtering) and return fields (name, email, phone, lifecycle stage), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing and searching contacts, with examples like 'Show my contacts' and 'Find contacts named John.' It provides clear context but does not explicitly mention when to use get_contact instead, so it lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It provides a useful detail about projects having their own status/task-type sets, but does not mention read-only nature, authentication requirements, or return format. This is adequate for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, with no redundant information. It is front-loaded with the action and resource in the first sentence, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description covers the core functionality and even adds a data-model insight (each project's own status/task-type sets). It does not specify return fields, but the simplicity of the tool makes this acceptable. The sibling list provides additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the baseline is 4. The description adds no parameter information, but none is needed; it confirms the tool takes no input and focuses purely on listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'task projects/pipelines for the workspace', using a specific verb and resource. It further distinguishes the tool by noting each project has its own status set and task-type set, setting it apart from sibling tools like list_pipelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example 'Show me my projects' implies when to use the tool, but the description does not explicitly state when to choose this over alternatives like list_pipelines or provide exclusions. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates a read-only operation ('List all subtasks') but does not disclose potential behavioral details such as required permissions, return format, pagination, or behavior when no subtasks exist. It is not misleading, but adds only minimal transparency beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a useful example, with no wasted words. It is front-loaded with the core purpose and the example enhances usability. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is nearly complete. It provides the core function, a related alternative, and an example. It could be improved by mentioning what is returned (e.g., a list of subtask objects) or handling edge cases, but for a simple listing tool, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already describes task_id as 'Parent task UUID'. The description adds an example ('Show subtasks of task <id>') and phrasing 'of a parent task', but this is largely redundant with the schema. It does not introduce additional semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all subtasks of a parent task.' This uses a specific verb ('list'), resource ('subtasks'), and context ('of a parent task'), and the example further clarifies usage. It distinguishes from siblings like list_tasks (which likely lists top-level tasks) and create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'List all subtasks of a parent task.' It also mentions an alternative for a related operation: 'To create a subtask, call create_task with parent_task_id.' However, it does not explicitly state when not to use this tool (e.g., for top-level tasks) versus list_tasks, so it falls slightly short of explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the return fields and implies filtering via the example 'Show active websites', but does not mention pagination, rate limits, or behavior when no sites match. This is adequate but not rich, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a concise example, with no filler. It front-loads the primary action and adds essential return-field details and usage examples in a compact, efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, so the description appropriately includes return field details and examples. It lacks explicit guidance on when to use this versus get_website, and does not mention pagination, but overall it provides sufficient context for an agent to select and invoke the tool correctly. Slightly incomplete due to the missing sibling differentiation, hence a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents both parameters (search and status) with descriptions and an enum, so schema coverage is 100%. The description adds only a minor hint about filtering via the example, without elaborating on search semantics or format. Baseline 3 is warranted as the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('websites'), scoped to 'your account'. It also distinguishes from siblings like get_website (which suggests a single site) and create_website, and even specifies return fields (name, CDN hostname, status, domain count), leaving no ambiguity about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (listing all websites in the account) and includes example prompts ('List my websites', 'Show active websites') that illustrate invocation and filtering. However, it does not explicitly mention when not to use it or name alternative tools, though the sibling list provides implicit contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the automatic CDN cache purge side effect, which is important. However, it does not specify whether deployment overwrites existing files, deletes omitted files, or what happens on failure, leaving some behaviors implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, all essential. It front-loads the main purpose, describes the input format, mentions a key side effect, and provides a concrete example. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description covers purpose, usage, side effect, and an example. It lacks details on return values or error behavior, but these are less critical for a conceptually simple deployment tool. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with thorough descriptions. The description adds minimal semantic value beyond referencing the file-to-content map and cache purge, which are already documented in the schema. The baseline of 3 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deploy multiple files to a website in one call' with a specific verb and resource. It also distinguishes from siblings like upload_file (single file) and purge_cache by emphasizing multiple files and automatic CDN cache purging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context by stating 'This is the best way to publish or update a website' and gives an example. It implies batch deployment as opposed to single-file upload but does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the phone-number prerequisite but does not describe what happens if the contact lacks a number, delivery confirmation, or any side effects. This is a partial disclosure, scoring a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource. The example is concise and useful, with no redundant wording. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema is complete for its parameters, and the description includes the key prerequisite. It lacks error-handling details, but for a straightforward SMS send action, the description is sufficiently complete. A 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's example illustrates message content but adds little beyond the schema properties. It does not explain UUID format or contact resolution, but the schema already covers parameter meaning adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Send' with the resource 'SMS text message', making the tool's action unambiguous. The example ('Send John a text saying...') clarifies natural-language usage and distinguishes this tool from sibling contact-management tools like create_contact or get_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states a precondition ('The contact must have a phone number on file'), giving context on when the tool can be used. It does not mention alternatives or explicit exclusions, but the context is clear enough for an agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully adds that content must be base64-encoded and that files are immediately available via CDN. However, it does not mention overwrite behavior, permissions, or size limits, which are relevant for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states the purpose, the second provides a critical constraint, and the third gives a concrete example. There is no fluff or repetition, and it is front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, no output schema, no annotations), the description covers the essential context: what it does, the base64 requirement, and CDN availability. It does not describe return values or error conditions, but these are less critical for a simple upload, and the schema already covers parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for all four parameters (100% coverage), so the baseline is 3. The description reinforces the base64 requirement for 'content' and gives an example, but it does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Upload a file to a website's storage.' This distinguishes it from sibling tools like delete_file, list_files, and create_folder, and the concrete example ('Upload index.html to my website') reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to upload file content to a website. While it does not explicitly name alternatives or exclusions, the sibling toolset (e.g., delete_file, create_folder) makes the distinction obvious, and the example provides practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key partial-update behavior, but omits other behavioral details such as error handling, permissions, or return value. This is better than a bare description but still leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: 'Update fields on an existing contact' immediately states purpose. The partial-update note and example are both relevant and non-redundant. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema. While the schema covers parameter descriptions fully, the description doesn't mention what happens if the contact doesn't exist, whether it returns the updated contact, or any validation behavior. It's adequate for basic selection and invocation but lacks some contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds crucial semantic meaning: omitting optional parameters leaves them unchanged, which is not stated in the schema. The example ('Update John's phone to 555-1234') illustrates usage of the phone parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update fields on an existing contact' with a specific verb and resource. It distinguishes update_contact from siblings like create_contact, delete_contact, get_contact, and list_contacts. The example adds practical clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when modifying an existing contact, and the partial-update note ('Only the fields you provide are changed') provides guidance on how to use optional parameters. However, it doesn't explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of disclosing behavioral traits. It clearly states the operation is permanent ('Permanently delete'), irreversible ('Cannot be undone'), and cascading ('all its resources: storage, CDN, files'). This is strong transparency for a destructive operation, though it doesn't mention prerequisites like domain removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one sentence stating the core action and scope, a warning about irreversibility, and a practical example. Every sentence earns its place with no redundancy, and the most critical information (permanence, cascade) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description provides essential context: what gets deleted, that it's irreversible, and an example. It could mention any additional consequences (e.g., domains or analytics), but the broad phrase 'all its resources' covers most expectations, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter site_id, describing it as 'The website ID (UUID) to delete'. The description's example uses a natural language site name, which might imply name-to-ID resolution but doesn't explicitly add parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('delete') and resource ('website'), and explicitly mentions the scope ('all its resources: storage, CDN, files'), distinguishing it from other delete tools in the sibling list like delete_file or delete_contact. The example further clarifies the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context through the example 'Delete the website called Test Site', implying the tool's use case without explicit alternative comparisons. It does not mention when-not-to-use or list alternatives, but the resource focus differentiates it well enough from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly communicates that the tool returns a detailed representation including comments, attachments, and subtask count. It does not mention error handling or side effects, but as a read operation, the description suffices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by an example. Every word earns its place, with no wasted length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers the tool's purpose, return content, and an invocation example. It does not need to explain return values or error cases at length.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents task_id as a UUID string with 100% coverage. The description's example ('Show me task <id>') adds a usage illustration but does not introduce new parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource ('Get full detail for a single task') and enumerates the response contents (fields, comments, attachments, subtask count), making it clearly distinct from sibling tools like list_tasks, update_task, or delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single task' strongly implies when to use this tool (fetching one task's details) versus listing tasks or performing mutations. The example 'Show me task <id>' provides practical context, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states that statuses are scoped per-project and clarifies the relationship between task_id and project_id. However, it does not explain behavior when both parameters are provided or when neither is provided, nor does it explicitly state that the tool is read-only (though 'List' implies this).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence followed by a useful example. It is front-loaded with the core purpose and contains no filler, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers the main behavior, scope, and usage. It does not mention what happens if both parameters are supplied or if no parameters are supplied, which is a minor completeness gap, but overall it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters. The description adds meaningful context by explaining that task_id resolves to its containing project and by offering an example usage, enhancing the semantic understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: list custom statuses for a project or a task's project. It distinguishes from sibling tools by emphasizing that statuses are scoped per-project, not per task_type, and includes a concrete example ('What statuses can I set on task <id>?') that eliminates ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual usage guidance via the example and the scoping note, implying when to use this tool. However, it does not explicitly name alternative tools or state exclusions (e.g., when not to use it), so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains what each type contains (key and label) and that task_id resolves to a project. However, it does not disclose whether the operation is read-only (safe) or if it has any side effects, nor does it mention any ordering, pagination, or filtering behavior. The description adds useful scoping behavior but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core verb and resource. It efficiently includes the key/label explanation and an example query. Every sentence earns its place; no redundant or filler information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 optional parameters, no output schema). The description explains the output concept (types with key and label) and the two usage modes (project_id or task_id). It could optionally mention that no parameters may list all types or require a project context, but the example and schema cover the main use cases. Given the simplicity and good schema coverage, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters documented in schema). The description adds meaningful semantics by explaining that task_id 'resolves to its project' and that one should omit project_id if task_id is provided, which clarifies their relationship beyond the schema. This goes beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('task types available for a project'), with clear scope: 'for a project (or for the project that contains a given task)'. It distinguishes itself from siblings such as list_task_statuses by focusing on types with key/label structure. The example query reinforces the purpose and usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'available for a project' and the alternative of providing a task_id to resolve to its project. It does not explicitly name alternatives or exclusions, but the context is clear enough to differentiate from list_task_statuses and other task-related tools. A slight gap is not stating when to prefer project_id vs task_id, though the schema and example imply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 disclosing side effects. It explicitly states that the underlying file is not deleted, which is the key behavioral distinction. It does not cover error cases or permission requirements, but given the simplicity of the operation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a short example, with no redundant or generic content. It front-loads the core action and uses the example to illustrate usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters, no output schema, and no annotations, the description covers the essential purpose, the main side-effect, and a usage example. It could add permission requirements or what the response looks like, but for this simple tool, the information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear field names and descriptions in the schema. The description adds the context 'display name' and an example that maps the parameters to real values, but it doesn't significantly extend beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove'), identifies the resource ('attachment from a task'), and specifies the method ('by its display name'). It also distinguishes this from file deletion tools by clarifying that the underlying file is not deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the attachment is removed but the underlying file persists, which helps an agent choose this over delete_file. It provides a concrete example showing the expected task context, though it doesn't explicitly name alternative tools or exclusionary conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It reveals that comments are appended to the recent_comments array and that auto-generated activity entries are preserved, giving useful side-effect detail. It stops short of discussing auth, rate limits, or error behavior, but covers the essential mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example. The main purpose is front-loaded in the first sentence, the second adds behavioral nuance, and the example is helpful without being verbose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema and no annotations, the description covers purpose, side effects, and usage example. It does not describe the return value or error cases, but these are not critical for such a straightforward operation. The key behavioral aspects are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described. The description adds an example showing how to structure comment content ('Comment on task <id>: spoke with client...'), which clarifies intended formatting beyond the bare schema. This extra semantic guidance lifts it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Add a comment to a task's activity timeline.' It clearly distinguishes this from sibling tools like add_task_attachment or update_task by specifying the comment action and timeline context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to append a comment to a task's activity timeline. It does not explicitly exclude alternatives or name when-not-to-use, but the scope is well-defined enough for an agent to select it appropriately among task-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It states that the tool lists all global variables and returns their current values, clearly indicating a non-mutating read operation. It does not detail authentication or rate limits, but for a zero-parameter read-only list tool, the description sufficiently conveys the behavioral scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, front-loaded with the core purpose. Every sentence contributes: the first defines the action and output, the second provides usage context and example phrasing. There is no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is complete enough: it states what is listed, includes the current values, and gives usage context. It does not detail the exact return format or edge cases like empty results, but these are not critical for a zero-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details, but none are needed since the schema already fully describes the input as an empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all global variables with their current values'), and clearly distinguishes this from sibling tools like list_websites or list_contacts. The scope is explicit: global variables used in templates, workflows, and agent prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that these variables are used in templates, workflows, and agent prompts, and gives example user queries ('Show my global variables' or 'What variables are set?'). It does not explicitly mention when not to use this tool or name alternatives, but no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns all built-in and custom fields with types and visibility, which is the key behavioral output. It doesn't mention side effects, but as a read-only list operation, this is adequate. It adds value beyond the empty schema by describing the return contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a helpful example. It front-loads the purpose in the first sentence, adds usage context in the second, and provides example queries. Every part earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what the tool does, what it returns, and when to use it. The example queries further aid the agent in recognizing invocation scenarios. No missing information is critical for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds nothing about parameters because there are none, so no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all contact fields (built-in and custom) with their types and visibility,' using a specific verb (list) and resource (contact fields). It distinguishes from siblings like list_contacts (lists contacts, not fields) and create_custom_field (creates fields).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains 'Useful for understanding what data you can store on contacts' and provides example queries, giving clear context for when to use it. It does not explicitly name alternatives or exclusion criteria, but the intended use is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently indicates a read-only listing behavior ('List all') and specifies the output fields ('pipeline name, stage names, and lead counts'), setting expectations for return content without hidden 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with a useful example, front-loaded with the primary action and outcome. Every word adds value, and the structure is clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description sufficiently covers what the tool returns and the scope. It mentions all pipelines, stages, and lead counts, providing enough context for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for 0 params is 4. The description doesn't need to explain parameter details because there are none, and the schema already confirms this with 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all sales pipelines with their stages, using the specific verb 'List' and resource 'sales pipelines.' It also distinguishes from siblings like list_task_statuses and get_pipeline_leads by focusing on pipeline and stage names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example user intents ('Show my pipelines' or 'What stages does my sales pipeline have?') provide clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the examples effectively convey appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![votel-mcp MCP server](https://glama.ai/mcp/servers/votelai/votel-mcp/badges/card.svg)](https://glama.ai/mcp/servers/votelai/votel-mcp)

Score Badge

Copy to your README.md:

[![votel-mcp MCP server](https://glama.ai/mcp/servers/votelai/votel-mcp/badges/score.svg)](https://glama.ai/mcp/servers/votelai/votel-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/votelai/votel-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server