weeek-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Many tools have overlapping purposes differentiated only by numeric suffixes (e.g., weeek_attach_a_tag, _2, _3), lacking clear target indication in names. Additionally, similar operations exist for different entities (deals, organizations, contacts) without disambiguation in the tool name, forcing reliance on descriptions.
Naming Consistency2/5
Naming follows a general weeek_verb_... pattern but is inconsistent: sometimes uses articles (weeek_get_a_contact) and sometimes not (weeek_get_tasks), and suffixes like _2, _3 are arbitrary. Some tools like weeek_tag and weeek_tag_list break the pattern. Overall, no consistent naming strategy across the set.
Tool Count1/5
154 tools is far too many for a single server. While the domain is broad (task management, CRM, etc.), the granularity is excessive; many operations could be combined via parameters. This extreme count overwhelms agents without clear benefit.
Completeness4/5
The server provides comprehensive CRUD and lifecycle operations for most entities (tasks, projects, contacts, deals, organizations, funnels, custom fields, etc.), including additional actions like move, attach, and archive. Minor gaps include lack of search endpoints and some missing list operations, but the core domain is well-covered.
Average 2.4/5 across 142 of 154 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the action is destructive, read-only, or has side effects. It lacks any behavioral traits 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, but it wastes space on redundant info ('POST /crm/organizations/{organizationId}/contacts', 'Tags: Organizations', 'Body: application/json') without being informative. It is under-specified, not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a minimal description, the tool is severely incomplete. It fails to explain what happens on success, error conditions, or prerequisites like whether the contact must already exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The schema indicates 'organizationId' and 'contactId' are needed, but the description adds no meaning or guidance on values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Attach a contact' and gives the HTTP endpoint, but it fails to specify what the contact is being attached to. The path implies attaching to an organization, but this is not clarified. The sibling tool 'weeek_attach_a_contact' without _2 suggests duplication with no differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'weeek_attach_a_contact' or 'weeek_detach_a_contact'. No context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only gives the HTTP method and endpoint. There is no information about authorization, side effects, idempotency, or what happens if the tag is already attached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than concise. It lacks essential information, so brevity here is a detriment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a minimal description, the tool definition is woefully incomplete. An agent cannot reliably select or invoke this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not describe any parameters (e.g., what tagId represents, how to find it, what organizationId expects). The schema alone is insufficient for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Attach a tag' and 'Tags: Organizations', which weakly suggests attaching a tag to an organization, but it does not explicitly state the target resource. It also fails to distinguish between attach_a_tag_2 and the many sibling attach tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other attach/detach tools, no prerequisites, and no context about the effect (e.g., idempotency, error conditions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details beyond the basic action. Without annotations, the description fails to disclose side effects, permissions, or idempotency. The action 'change board' implies mutation but no confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but sacrifices essential information. Conciseness is not beneficial when it omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the nested parameters, the description is grossly incomplete. It provides no context on expected input or output behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any parameter. The boardId and id parameters are not described, leaving the agent uninformed about required values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the HTTP method and path, but 'Change board' is ambiguous and does not differentiate from sibling tools like weeek_change_board_column. It lacks specifics on what board change entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 reveals nothing about the behavior of moving (e.g., reordering position, effects on tasks, permissions, or reversibility).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not usefully concise; it lacks substance. It provides no real information beyond the tool name and HTTP method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, no output schema, and no annotations, the description is completely inadequate for an agent to correctly invoke the tool. It does not specify what 'move' entails or how to provide parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any parameters. The key parameter 'upperBoardColumnId' is not described, leaving its purpose unclear (target position or destination?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move board column' is a minimal verb+resource, but it is vague and does not explain what 'move' means (e.g., reorder vs. relocate to another board). It lacks differentiation from sibling tools like weeek_change_board_column.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool. There are many sibling tools for moving/changing board columns, boards, and tasks, but the description provides no context or alternatives.
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 the full burden. The mention of 'GET' implies a read operation, but it does not explicitly state safety, auth needs, or other behavioral traits. The description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but it is under-specified rather than concise. It lacks critical information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many parameters, nested objects), the absence of output schema, and no annotations, the description is completely inadequate for an AI agent to understand the tool's behavior, return format, or usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the tool description adds no information about parameters. The schema itself has descriptions, but the description fails to provide any additional context or guidance for the many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Get tasks', which is a tautology of the title. It does not distinguish itself from sibling tools like weeek_get_one_task_info or weeek_get_all_contacts. The HTTP path adds a minimal hint but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided about when to use this tool versus alternatives, no prerequisites, and no context for 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.
Behavior1/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 behavioral traits. It only says 'Update tag.' without any details on whether updates are destructive, idempotent, or what permissions are needed. There is no mention of side effects on associated entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It includes the HTTP method and path but no structured explanation. A concise description should be informative yet brief; this is merely brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single-line description, the tool is not contextually complete. It lacks information about return values, error handling, tag behavior, or any related concepts. Agents would be left guessing about the tool's usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning no parameter descriptions exist. The description adds no additional meaning about the parameters. The schema defines 'body.title' and 'body.color' but their purpose is not explained. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update tag.' which is a clear verb+resource pair. However, it does not distinguish this from sibling tools like 'weeek_create_tag' or 'weeek_delete_tag', and provides no context on what aspects of the tag can be updated. It is minimally adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. No when-to-use, when-not-to-use, or prerequisites are mentioned. Siblings like 'weeek_create_tag' and 'weeek_delete_tag' have similar lack of guidance, but the description does nothing to help an agent choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only restates the HTTP method and endpoint, failing to disclose whether the add is appending or replacing, permissions required, idempotency, or side effects. A POST mutation tool requires more 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant technical details like the full HTTP path and 'Tags: Task'. While concise, it lacks critical information about functionality and parameters, making it underspecified rather than efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools for assignee management and a nested schema, the description is severely incomplete. It does not explain how this tool relates to 'attach_an_assignee' or 'remove_assignee', lacks return value info (no output schema), and leaves parameter usage ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to the parameters. It does not clarify what 'assignees' expects (user IDs, emails?), nor the format of 'taskId'. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add assignees' and specifies the HTTP endpoint, making the verb and resource clear. However, it does not distinguish this tool from siblings like 'weeek_attach_an_assignee' or 'weeek_remove_assignee', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, restrictions, or context for when to add assignees vs. attach/detach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not state whether the transfer is a move or copy, what happens to the original custom field, any required permissions, or side effects. The minimal description fails to inform the agent about the operation's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not effectively concise—it repeats the tool name and HTTP path without providing structured or useful information. There is no front-loading of key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested parameters and the presence of many sibling transfer tools, this description is completely inadequate. It does not explain the operation's effect, return value (no output schema), or how it differs from similar tools. The agent lacks essential context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to parameters. The parameter names (e.g., 'id', 'project_id', 'boardId') are self-explanatory to some extent, but the description does not clarify their roles or constraints beyond what the schema defines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology, repeating the tool name and the HTTP path. It says 'Transfer custom field to board' which adds no new information beyond the name. It does not distinguish from sibling tools like 'weeek_transfer_custom_field_to_project' or 'weeek_transfer_custom_field_to_task_manager'.
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 provided on when to use this tool versus alternatives. It lacks any context about prerequisites, scenarios, or exclusions. Sibling tools with similar purposes are not mentioned for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., whether the transfer removes the field from the original location, any side effects, or required permissions). The HTTP method POST is implied but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but repeats the HTTP endpoint unnecessarily. It could be reduced to just 'Transfer custom field to project.' without the URL, making it more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, 0% schema coverage, and nested objects, the description is wholly inadequate. It fails to explain the transfer behavior, required inputs, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. It only mentions 'Body: application/json' without explaining the purpose of body.projectId, path.project_id, or path.id. The schema shows two nested objects with required fields but no semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Transfer custom field to project' which is a verb+resource but lacks specificity. The meaning of 'transfer' is unclear—does it move the field from one project to another or copy it? Among many sibling transfer tools (e.g., transfer to board, transfer to task manager), no differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., weeek_transfer_custom_field_to_board, weeek_transfer_global_custom_field_to_project). No context about prerequisites or scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear full responsibility. It only mentions the HTTP method and path, offering no details on permissions, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this brevity comes at the cost of essential information. It lacks structure and fails to convey necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools and the complexity of creating a tag, the description is completely inadequate. It does not explain what a tag is, how it relates to other entities, or what the return value looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters. The description does not explain the 'body' structure or the 'title' field, leaving the agent to guess the meaning and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create tag' which is a clear verb+resource combination. However, it does not differentiate this from sibling tools like weeek_attach_a_tag or weeek_update_tag, making it vague in context.
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 provided on when to use this tool vs. alternatives, or any prerequisites. The user is left without context for selection.
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, and the description does not disclose any behavioral aspects such as destructive potential, authorization requirements, or side effects. The agent cannot assess safety or implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description includes extraneous details (HTTP method, tags) and fails to provide essential information. It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects and no output schema, the description is severely incomplete. It lacks details about the operation's effect, required permissions, and return values, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameter meanings (e.g., upperBoardId, path id). It adds no value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Move board' but does not clarify what moving a board entails (e.g., reordering, changing parent). It essentially repeats the tool name, providing minimal differentiation from siblings like 'weeek_change_board' or 'weeek_move_board_column'.
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?
There is no guidance on when to use this tool versus alternatives. No context about prerequisites, when not to use it, or comparison to similar tools is provided.
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 convey behavioral traits. It mentions the HTTP method and path and that the body is JSON, but does not disclose side effects, permissions, or update semantics (e.g., partial vs full update).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but lacks essential information. It is under-specified rather than concise, failing to add value in its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters with nested objects, no output schema, and many siblings, the description is far from complete. It does not address return values, error conditions, or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for parameters 'body' or 'path'. It does not define 'id' or 'name', leaving the agent without context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update board column' which is a clear verb-resource pair. However, it does not differentiate from sibling tools like 'weeek_change_board_column', leading to ambiguity for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'weeek_change_board_column' or 'weeek_move_board_column'). The description omits any context for appropriate usage.
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 only mentions the HTTP method (DELETE) implying destructiveness, but does not elaborate on side effects, permission requirements, or whether the operation is reversible. This is insufficient for an agent to assess risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loads the HTTP method, which is useful. However, the brevity comes at the cost of missing critical information; it is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters with nested objects, no output schema, and many sibling tools. The description provides no context on behavior, prerequisites, side effects, or return values. It is completely inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing to explain the parameters. The path's dealId and body's tag are mentioned only structurally; no meaning, constraints, or relationship to other entities is described. The agent would have no semantic understanding beyond types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Detach a tag' and includes the HTTP method and endpoint, indicating it removes a tag from a deal. However, there are multiple sibling tools with similar names (weeek_detach_the_tag, weeek_detach_the_tag_2) and no differentiation is provided, making it ambiguous which tool to use for specific scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus alternatives, no exclusions, and no prerequisites. Given many sibling tools with similar purposes, this omission is critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It fails to disclose any behavioral traits such as side effects (e.g., recording time), required permissions, or error handling. The description is a mere restatement of the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of completeness. It contains redundant information (repeating the title and including an irrelevant tag). Every line should add value, but here the description does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of schema descriptions and output schema, the description should provide more context on the operation, return value, and error states. It is entirely inadequate, leaving the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds no meaning to the 'path' parameter or its nested 'id'. It does not explain what the ID represents (presumably a task ID) or provide any format/validation hints. The description fails to compensate for the missing schema descriptions.
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 stops a task timer, with a specific verb and resource. It implicitly distinguishes from the sibling 'weeek_start_task_timer' by being the inverse action. However, it is somewhat tautological, repeating the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool, when not to, or any prerequisites (e.g., that a timer must be running). Without this, an AI agent might attempt to stop a non-existent timer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Delete the address.' It does not disclose any behavioral traits such as irreversibility, required permissions, impact on related data, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but sacrifices informativeness for brevity. The endpoint and tag are front-loaded, but the lack of meaningful content makes it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a delete operation and the presence of sibling delete tools, the description provides insufficient context for an AI agent to use it correctly. Missing key details like parameter structure and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions and 0% coverage. The description mentions the endpoint but does not explain what organizationId or addressId represent or how to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it deletes an address, which is clear from the name, but adds only the HTTP endpoint and tag. It does not differentiate from other delete tools for related entities (e.g., deleting contacts, organizations).
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 on when to use this tool versus alternatives like updating the address or deleting other resources. No prerequisites or conditions mentioned.
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. It specifies that the tool uses the DELETE HTTP method, implying destructive action, but does not detail side effects, required permissions, rate limits, or error states. Behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus endpoint), but it is not well-structured. The mixing of HTTP method, path, and fragmentary notes ('Tags: Organizations. Body: application/json') reduces clarity. It could be more concise and readable with proper formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, nested objects, no output schema, and siblings with similar functionality, the description is incomplete. It lacks explanations of return behavior, success/failure indicators, and context for when to use this specific detach operation over others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the parameters (organizationId in path, tagId in body). It only mentions 'Body: application/json' without clarifying what the body contains or the role of each parameter. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Detach the tag' and provides the endpoint DELETE /crm/organizations/{organizationId}/tags, indicating it removes a tag from an organization. However, it is vague about the resource context (what 'tag' refers to) and does not clarify the meaning of 'Tags: Organizations'. The purpose is discernible but lacks specificity.
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 on when to use this tool versus alternative sibling tools like weeek_detach_a_tag or weeek_detach_the_tag_2. There is no mention of prerequisites, use cases, or conditions under which this tool is appropriate.
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 must carry the behavioral burden, but it only states 'Move a attached to the deal task' and provides the HTTP method. No disclosure of what the move does (e.g., reorder, change parent), whether it is destructive, or what permissions are required. The agent remains uninformed about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, which is efficient, but it lacks essential information. It front-loads the HTTP method and path, which is good, but the remaining content is redundant or unhelpful. It earns a 3 for brevity but loses points for not earning its place with substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameters, no annotations or output schema), the description is severely incomplete. It does not explain what a 'move' entails, what the response looks like, or how to use the parameters. For a tool with many siblings, this lack of context makes it nearly impossible to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no parameter explanations. It only mentions 'Body: application/json'. The schema has nested objects with properties like 'previousTaskId' (with a description in the schema) and path parameters, but the description does not clarify them. The agent must infer meaning solely from the schema, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move a attached to the deal task' is vague and nearly identical to the title. It fails to specify what is being moved (a task within a deal's task order?) and does not distinguish it from sibling move tools like 'weeek_move_a_deal' or 'weeek_move_board'. The HTTP path and tag provide technical context but not clear purpose.
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 the many other move-related tools. There is no mention of prerequisites, context, or exclusions. The agent has no basis to choose this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only mentions the HTTP method and body format, omitting critical details such as whether the operation is idempotent, requires specific permissions, or what happens if the tag is already attached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but fails to convey essential information. It is under-specified rather than concise; every sentence should add value, and here the value is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested input schema and lack of output schema, the description should explain return values, errors, or usage context. It provides none of these, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only states 'Body: application/json' without explaining the required parameters (tagId, contactId) or their formats. The schema alone provides no descriptions, leaving the agent uninformed.
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 action (attach a tag) and resource (contacts/{contactId}/tags), including HTTP method. However, it does not differentiate between multiple similar attach_tag tools (e.g., weeek_attach_a_tag, _2), reducing clarity for distinguishing siblings.
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 provided on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions. The description simply states the action.
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, and the description only gives the HTTP method and endpoint. It does not disclose side effects, permissions, idempotency, or expected outcomes beyond creating a funnel.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three fragments), but it is not front-loaded with the most critical information. It wastes characters on the endpoint path and tags, which are less important than usage guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested parameter object and no output schema, the description fails to explain the purpose of each field, the expected response, or how a funnel fits into the CRM. It is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'Body: application/json'. No explanation of what 'name', 'isPrivate', or 'currencyId' mean or how they affect the funnel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a funnel', which is clear but nearly identical to the tool title. It fails to differentiate from sibling tools like 'weeek_create_a_funnel_status' as it does not clarify what a funnel is or how it differs from other entities.
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 on when to use this tool versus alternatives (e.g., updating or deleting a funnel). No prerequisites or context for usage are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but discloses no behavioral traits (e.g., idempotency, side effects, effects on linked data). Merely stating 'Delete' is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though short, the description includes redundant HTTP method and a tags line without adding value. It fails to earn its length by providing meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and many sibling tools, the description omits critical information about deletion behavior, scope, and differentiation, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the purpose of custom_field_id or id, nor how to obtain them. The path pattern is shown but adds no semantic meaning.
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 action (delete) and resource (global custom field option), and includes the HTTP path. However, it does not explicitly differentiate from similar sibling tools like weeek_delete_a_custom_field_option, leaving ambiguity about scope.
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 provided on when to use this tool versus alternatives (e.g., project-level deletion), no prerequisites mentioned, and no when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral disclosure. With no annotations, the description must inform about consequences, but it only states 'Delete task' without mentioning permanence, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is under-specified rather than concise. It provides minimal value and omits essential details, making it inefficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (delete operation, many siblings) and absence of output schema, the description is severely incomplete. The agent cannot safely or correctly invoke the tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the only parameter (path.id), leaving ambiguity about its source or format. The schema defines it as string or number, but no context is added.
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 action ('Delete task') and HTTP method, making the purpose evident. However, it does not differentiate from sibling delete tools like 'weeek_delete_project' or 'weeek_delete_board' beyond the resource type.
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 provided on when to use this tool versus alternatives, such as conditions for deletion, prerequisites, or irretrievability. The agent receives no help in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral disclosure. No annotations are provided, so the description must cover aspects like irreversibility, permission requirements, or side effects. It only states 'Delete the phone', omitting critical information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant information ('DELETE /crm/organizations/{organizationId}/phones/{phoneId}') that repeats the tool name and schema. It fails to provide useful content in a concise manner, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (delete operation with nested parameters, no output schema, no annotations), the description is severely incomplete. It does not specify what happens after deletion, response format, or any dependencies, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'path' parameter or its sub-properties organizationId and phoneId. The input schema is empty of descriptions, and the tool description adds no meaning beyond the schema structure.
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 'Delete the phone', specifying the action and resource. However, it does not differentiate from the sibling tool weeek_delete_the_phone_2, which likely deletes a different phone entity.
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 usage guidelines are provided. There is no indication of when to use this tool versus alternatives like weeek_delete_the_phone_2, nor any prerequisites or context like the need for an existing organization and phone ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as whether moving is destructive, requires permissions, or has side effects. The description is minimal and fails to inform the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but at the expense of critical information. It is a single line that does not earn its place as it omits essential details like parameter explanations and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested input schema and the absence of annotations or output schema, the description is woefully incomplete. It fails to explain the behavior, return values, or prerequisites for moving a custom field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no value beyond what the schema provides. The 'after' and 'before' parameters are documented in the schema, but the description does not explain their semantics or the required path parameters.
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 explicitly states 'Move a custom field' and includes the HTTP path, clearly indicating the action and resource. However, it does not differentiate itself from sibling tools like 'weeek_move_a_custom_field_option', which could cause confusion. Still, the core purpose is clear.
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 provided on when to use this tool versus alternative move tools. There is no mention of prerequisites, context, or exclusions. The description lacks any usage direction.
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?
The description indicates a DELETE operation, implying destructiveness, but no annotations are provided. It lacks details on error scenarios, permission requirements, or side effects (e.g., what happens if the assignee does not exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines), but includes extraneous details like 'DELETE /tm/tasks/{taskId}/assignees' and 'Tags: Task' that could be considered metadata. It is concise but not optimally structured for agent usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of two parameters (including a nested body) and no output schema or annotations, the description is woefully incomplete. It fails to explain parameter format, return values, or any behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. It only mentions 'Body: application/json', but does not describe the required 'assignees' array or the 'taskId' path parameter. The agent gains no additional understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remove assignee' and provides the HTTP method and path, which gives a basic understanding. However, it does not clearly specify that it removes assignees from a task, which is implied but not explicit. It also does not distinguish from sibling tools like 'weeek_detach_an_assignee'.
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 on when to use this tool versus alternatives such as 'weeek_add_assignees' or 'weeek_detach_an_assignee'. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states the endpoint, with no mention of side effects, authentication, rate limits, or return behavior. This is insufficient for an agent to invoke safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concise; it is cryptic and contains redundant words. It fails to front-load the most important information. Every word should add value, but here some are wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values or behavior. It does not. The tool is simple (fetch a tag), but the description omits essential details like response format or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter 'path' with nested 'id', but schema description coverage is 0%. The description does not explain how to use the parameter or what values are expected. The agent must guess the meaning of 'id'.
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 includes the HTTP method and endpoint, clearly indicating a GET request to retrieve a tag by ID. However, the repetitive 'Tag. Tags: Tags.' adds noise and lacks natural language that explicitly states 'get a tag'. It is somewhat clear but could be more direct.
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 provided on when to use this tool versus alternatives like weeek_tag_list or others. The description does not mention context, prerequisites, 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?
With no annotations, the description must disclose behavioral traits. It only says 'Un complete task' without mentioning side effects, authorization needs, reversibility, or potential data changes. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the inclusion of an HTTP method and path ('POST /tm/tasks/{id}/un-complete') adds unnecessary technical detail that may confuse an agent. The core purpose is not front-loaded or clearly structured.
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?
Given no annotations, no output schema, and two parameters with minimal schema description, the description fails to provide a complete picture. Missing return value info, error handling, and prerequisites leave significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'Body: text/plain' but does not explain the body's content or the 'id' parameter in the path. The nested object 'path' is undocumented, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the name ('Un complete task') without clarifying the action's meaning or distinguishing it from similar tools like 'weeek_complete_task'. It fails to specify what 'un-completing' entails, making it a near-tautology.
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 on when to use this tool versus alternatives (e.g., 'weeek_complete_task'). The description lacks context about prerequisites or scenarios, leaving the agent without decision-making support.
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 but only indicates a PUT request. It fails to disclose behavioral traits such as permissions required, side effects on existing custom fields, or error handling. The agent gains little insight into the mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which could be considered concise, but it omits critical information needed for correct tool usage. It is structured as a single sentence but does not add value beyond the tool name and endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameters, conditional fields, multiple sibling tools) and lack of output schema, the description is grossly incomplete. The agent lacks essential details to invoke the tool correctly and understand its effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of parameters. It merely notes 'Body: application/json'. The complex nested schema is left entirely undocumented, leaving the agent without guidance on how to construct valid requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool updates a custom field and provides the HTTP method and path. However, it does not differentiate from sibling tools like weeek_update_a_custom_field or weeek_update_a_custom_field_2, leaving ambiguity about which update tool to use.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions for updating custom fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Update the phone' with the HTTP method. It does not disclose traits such as idempotency, permission requirements, side effects, or error handling. The agent has no behavioral insights beyond the obvious mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but lacks necessary detail. It is under-specified rather than concise, omitting critical context like param semantics and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of two nested parameters and no output schema, the description fails to provide a complete picture. It does not explain the update scope, return format, or behavior, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description adds no meaning to the parameters, failing to explain what 'phone' in the body or the path IDs represent or their constraints.
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 states the HTTP method and path, indicating an update operation on a phone resource. However, it does not distinguish from sibling tool weeek_update_the_phone_2, which likely updates a different phone type or context. The purpose is clear but lacks differentiation.
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 on when to use this tool versus alternatives like create or delete phone. The description provides no context on prerequisites, best practices, 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?
With no annotations, the description must disclose behavioral traits, but it only states 'Complete task' without explaining what that entails (e.g., status change, irreversibility, side effects). This is minimal disclosure.
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 extremely concise (one sentence) and includes the endpoint, which is efficient. However, it lacks structure and could be improved by separating different pieces of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested schema, no output schema, many sibling tools), the description is woefully incomplete. It fails to explain the effect of completing a task, return value, or how it differs from similar tools like 'weeek_update_a_task'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description must explain parameters, but it only mentions 'Body: text/plain' without describing the body's purpose or the required 'id' path parameter. The schema itself is complex with nested objects, yet the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it completes a task ('Complete task') and provides the HTTP method and path, which helps identify the purpose. However, it does not distinguish this tool from other task-related tools like 'weeek_update_a_task' or 'weeek_change_board', which could also affect task state.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., task existence) or when not to use it (e.g., if task is already complete).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It only states 'Delete the email' without any details on consequences (e.g., permanence), authorization needs, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), which is efficient but lacks substance. It includes the HTTP method and tags, but these are redundant with the name and provide minimal additional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested parameters, no output schema, no annotations, and multiple sibling tools, the description is severely incomplete. It fails to explain which email is being deleted, the scope, or what the response entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no information about the 'path' parameter or its subfields (organizationId, emailId). The agent receives no help understanding parameter semantics.
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 explicitly states 'Delete the email' with the HTTP DELETE method, clearly indicating the action and resource. However, it does not differentiate from the sibling tool 'weeek_delete_the_email_2', which likely deletes a different email resource.
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 provided on when to use this tool versus alternatives like 'weeek_delete_the_email_2' or other delete tools. No prerequisites, context, or exclusions are mentioned.
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 provided. Description indicates a DELETE request (destructive) but lacks details on side effects, idempotency, permissions, or error conditions. The behavioral impact is under-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short, but includes the HTTP method and endpoint which may be unnecessary. Lacks structured breakdown; reads like a raw note.
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?
Despite no annotations and no output schema, the description does not cover return values, errors, or full functionality. Incomplete for a tool with nested parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any parameters. Required fields (contactId, tagId) are not described. The agent cannot determine how to obtain valid IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Detach the tag' and the endpoint suggests detaching from a contact, but it does not differentiate from other detach tag tools (e.g., weeek_detach_a_tag, weeek_detach_the_tag). The verb and resource are clear but sibling differentiation is lacking.
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 on when to use this tool over alternatives like other detach tag tools. No prerequisites or context for when detaching a tag is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It only states 'Update' and the HTTP method, implying a mutation. It fails to mention side effects, required permissions, or whether changes propagate to existing tasks. This is critically insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus HTTP path and tags). It is not verbose, but lacks substantive guidance. It earns a middle score for being concise yet under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameters, no output schema) and many sibling tools, the description is severely incomplete. It does not explain what a global custom field option is, how to obtain IDs, or what the response looks like. The agent would lack critical context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the input schema. The schema itself includes a nested body with name and color, but the description does not explain what these parameters do or how to obtain path IDs. Since coverage is low, the description should compensate but does not.
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 HTTP method and resource path, and indicates the action is 'Update global custom field option.' This is specific, but it does not differentiate from sibling tools like 'weeek_update_a_custom_field_option' which might update non-global options. The name already suggests global scope, but description could clarify the distinction.
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 provided on when to use this tool versus alternatives (e.g., weeek_update_a_custom_field_option, weeek_create_global_custom_field_option). The description does not indicate prerequisites or context, leaving the agent to guess.
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?
The description lacks behavioral details beyond stating it's a POST request that creates a custom field. It does not disclose idempotency, permission requirements, side effects (e.g., if a field already exists), or post-creation behavior. With no annotations, this leaves 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one line), but this brevity comes at the cost of useful information. It is under-specified and fails to provide essential context, such as the purpose of tags or the format of the request body.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested input schema, no output schema, 2 parameters) and the abundance of sibling tools, the description is severely incomplete. It does not explain the board context, the types of custom fields, or the significance of the 'config' object, leaving the agent uncertain about correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% schema description coverage, meaning the description adds no explanatory value for the parameters. It does not clarify the role of 'body' vs 'path', or the complex 'config' object, which is critical for correct invocation.
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 'Create a custom field' and provides the HTTP method and endpoint, establishing the verb and resource. However, it does not differentiate from sibling tools like weeek_create_a_custom_field and weeek_create_a_custom_field_3, which share similar names.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or exclusions, and the existence of multiple custom field creation tools (weeek_create_a_custom_field, weeek_create_a_custom_field_3) is not addressed.
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 should disclose behavioral traits. It only states the HTTP method and content type, but does not mention authorization requirements, idempotency, side effects, or return values. The agent is left uninformed about critical behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it sacrifices essential information. It front-loads a technical endpoint path rather than a clear statement of the tool's value. Every sentence is minimal, but the lack of depth makes it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description must be comprehensive. It fails to explain what a custom field option is, how the parameters fit together, or what the result of creation looks like. The tool is complex with nested objects, and the description leaves many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to parameters. It does not explain the purpose of 'name' or 'color', nor the meaning of 'funnel_id' and 'custom_field_id'. The only extra detail is 'Body: application/json', which is not about semantics.
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 action ('Create') and the resource ('custom field option'). However, it does not distinguish from sibling tools with identical titles and similar purposes, such as weeek_create_a_custom_field_option and weeek_create_a_custom_field_option_2.
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 on when to use this tool versus alternatives. No prerequisites (e.g., existing funnel and custom field) are mentioned. The description lacks context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavioral traits. It fails to mention that this is a destructive irreversible action, any required permissions, side effects, or rate limits. The description lacks essential transparency.
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 concise at two sentences, front-loading the HTTP method and path. However, it sacrifices necessary detail for brevity, resulting in under-specification for a complex delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a delete operation with nested parameters and no output schema or annotations, the description is woefully incomplete. It lacks parameter descriptions, usage context, and behavioral disclosure, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for the parameters (id, funnel_id, custom_field_id). The URL template hints at their purpose, but the description does not clarify their roles, types, or constraints beyond what is in the 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 'Delete a custom field option' and provides the HTTP method and endpoint URL, making the purpose unambiguous. However, it does not differentiate this tool from sibling tools like weeek_delete_a_custom_field_option or weeek_delete_a_custom_field_option_3.
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 provided on when to use this tool versus alternatives, nor are any prerequisites or exclusion criteria mentioned. The description merely states the action without contextual usage advice.
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 only mentions HTTP method and tags, but does not state that it is read-only, safe, or idempotent. Lacks critical 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely short (three fragments) and mostly repeats the title. It lacks structured information; every sentence should add value, but here it adds none beyond redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested input schema (object with required projectId) and no output schema, the description provides almost no context. The agent cannot understand how to invoke the tool correctly or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description adds no meaning to parameters. The required projectId is not explained; the agent cannot infer its purpose or usage from the description alone.
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?
Description states 'Get board list' which clearly identifies the action and resource. However, it lacks differentiation from sibling tools like weeek_get_project_list or weeek_get_board_column_list, but the purpose is still clear.
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 on when to use this tool vs alternatives. Missing context on prerequisites (e.g., need a projectId) or when not to use it. The description does not help the agent decide.
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 fully disclose behavior. It only says 'Transfer custom field to task manager' without explaining side effects, permissions, or what happens to the original field. This is insufficient 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but underspecified. It is not appropriately sized for the complexity; it lacks critical information. Being concise without substance is not good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one parameter that is a nested object, no output schema, and many siblings), the description is completely inadequate. It does not explain the transfer process, prerequisites, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. It only repeats the endpoint pattern, but the meaning of 'project_id' and 'id' (which identifier for custom field?) is not clarified. The description adds no value over the 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 states 'Transfer custom field to task manager', which is a clear verb+resource. However, it does not differentiate from siblings like 'weeek_transfer_custom_field_to_board' or 'weeek_transfer_custom_field_to_project', so the purpose is clear but lacks sibling differentiation.
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 on when to use this tool versus alternatives. No exclusions or context provided. The description does not help the agent decide between this and similar transfer 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?
No annotations provided; the description only mentions HTTP method and request body type. It does not disclose idempotency, required permissions, error behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential details. It is under-specified rather than truly concise; every sentence is present but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and minimal description, the agent lacks sufficient context to use the tool correctly. Complex parameters like customFields are unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about parameters beyond the schema. With 0% schema description coverage, the description should explain the path parameter 'id' and body fields, but it does not.
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 'Update a deal' which identifies the verb and resource. However, it does not distinguish from the similarly named sibling 'weeek_update_a_deal_fields' which could cause confusion.
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 on when to use this tool versus alternatives (e.g., 'update_a_deal_fields'). No prerequisites, exclusions, or context provided.
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?
The description only reveals that it is a PATCH operation, implying partial updates, but does not disclose other behavioral traits such as idempotency, permission requirements, or side effects. With no annotations, more detail is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the expense of clarity and completeness. It includes a redundant 'Tags: Deals' line that adds no information beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, many optional fields, no output schema), the description is grossly insufficient. An agent cannot infer required fields, data formats, or response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, despite the input schema containing two complex objects (path, body) with many properties. Schema description coverage is 0%, so the description adds no value beyond the raw 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 verb 'Update' and resource 'deal fields', making the purpose unambiguous. However, a sibling tool 'weeek_update_a_deal' exists with a very similar name, and the description does not differentiate between them, which could cause confusion.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'weeek_update_a_deal' or other deal-related tools). It lacks context on prerequisites, typical use cases, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions the HTTP method (PUT) without disclosing side effects, idempotency, permissions, or error behavior. Fails to compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very short, the description omits essential information, sacrificing clarity for brevity. The endpoint info may be helpful, but the overall structure is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fails to mention return values, error conditions, or the body format. Given the nested objects, it is critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters beyond the path template. No details about the body's email field or the path IDs, leaving the agent without meaning.
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 'Update the email' and provides the endpoint pattern, specifying the resource and action. However, it does not differentiate from the sibling 'weeek_update_the_email', causing potential confusion.
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 on when to use this tool versus alternatives like 'weeek_update_the_email' or 'weeek_create_an_email_2'. Lacks context on prerequisites or conditions.
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?
Without annotations, the description fails to disclose critical behavioral details such as whether adding watchers is idempotent, what happens on duplicate watchers, authentication requirements, or rate limits. It only states the HTTP method and tags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (22 words) but lacks structure. It combines the HTTP method, endpoint, action, tags, and body format in a single line. While not verbose, it sacrifices readability and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameters, no output schema, no annotations), the description is woefully incomplete. It does not explain input requirements, response format, error conditions, or usage context. A tool with two parameters requires more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters at all. It mentions 'Body: application/json' but does not describe the `watchers` array format or the `task_id` path parameter. With 0% schema description coverage, the agent receives no guidance on parameter values.
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 explicitly states the action ('Add watchers to a task') and provides the HTTP endpoint, making the tool's purpose immediately clear. It distinguishes from siblings like 'remove_watchers_from_a_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, what prerequisites (e.g., task existence), or alternatives. The sibling list includes many related tools, but no comparison is given.
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?
The description implies a mutation (archiving) but provides no details on side effects, reversibility, or access requirements. No annotations exist to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy ('Archive project' repeats the title) and includes technical HTTP details that may not be essential for an agent.
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?
Given no output schema, no annotations, and minimal parameter explanation, the description lacks completeness. It does not explain the effect of archiving or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite having two parameters (body, path.id) with 0% schema description coverage, the description adds no parameter information beyond 'Body: text/plain', which is about content type, not the parameter itself.
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 'Archive project' and provides the HTTP method and path, making the action identifiable. However, it does not differentiate from the sibling tool 'weeek_un_archive_project' or explain what archiving entails.
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 on when to use this tool versus alternatives, no prerequisites mentioned, and no context for appropriate usage scenarios.
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 behavioral details beyond the action. Does not disclose side effects, error conditions, or what happens to existing assignees. With no annotations, the description carries the full burden but provides minimal info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it sacrifices necessary detail. It is not efficiently conveying essential information; it's underspecified.
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?
Given the complexity (nested objects, no output schema, no annotations), the description is incomplete. It does not explain the tool's role in the CRM domain or what 'attach' means operationally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. It only notes 'Body: application/json' but gives no meaning for assigneeId or dealId, leaving the agent to rely solely on the schema with no added context.
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 states 'Attach an assignee' and provides the endpoint, making the verb and resource clear. However, it does not differentiate from sibling tools like 'weeek_add_assignees' which may serve a similar purpose.
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 on when to use this tool versus alternatives. No mention of prerequisites, contexts, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to mention behavioral traits such as whether the task is reordered, what happens to subtasks, or any side effects. The presence of 'after' and 'before' parameters hints at ordering but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, but includes redundant elements like 'Tags: Task' and the full endpoint. While short, it sacrifices informativeness. Every sentence earns its place but lacks substance.
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?
Given no output schema, no annotations, and complex nested parameters, the description is incomplete. It does not describe the request/response format, the effect of optional parameters, or the outcome. For a mutation tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. It does not explain the purpose of 'parentId', 'after', or 'before', which are crucial for correct invocation. The agent has to rely solely on the parameter names.
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 'Change task parent', which indicates the verb and resource. It also includes the HTTP method and endpoint, distinguishing it from siblings like weeek_change_board or weeek_complete_task. However, it could be more specific about what changing parent entails.
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?
The description provides no guidance on when to use this tool versus alternatives. Among many sibling tools for task updates, no context is given for when changing the parent is appropriate or what prerequisites exist.
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 absent, so the description must carry the full burden. It only reveals that the tool creates a contact via a POST request. There is no mention of permissions, idempotency, error conditions, or what happens on duplicate names. Minimal behavioral context is provided.
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 very short (one sentence plus endpoint and tags) and to the point. However, it sacrifices necessary detail for conciseness. While not verbose, it could be more structured with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested input schema, many parameters, no output schema, and no annotations, the description is severely incomplete. It lacks information about return values, field constraints, and behavioral details, making it insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to explain any parameters. It only notes 'Body: application/json' without describing the body fields (firstName, lastName, emails, etc.). The agent must rely solely on the schema names, which is insufficient for correct invocation.
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?
Description states 'Create a contact' and provides the POST endpoint, clearly indicating the action and resource. However, it does not differentiate from sibling creation tools like weeek_create_an_organization or weeek_create_a_deal, though the name and title already specify 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as weeek_attach_a_contact or weeek_update_a_contact. The description provides no context about prerequisites or typical use cases, leaving the agent to infer from the name alone.
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 given, so the description bears the full burden of behavioral disclosure. It only states the action and HTTP details, omitting side effects, permissions, idempotency, or error conditions. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is front-loaded with the HTTP method and path. However, it lacks substance beyond technical details, which would make it insufficient for an agent to understand its purpose relative to siblings.
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?
Given the lack of output schema and the presence of nested objects, the description should explain what the option represents and what the API returns. It does not, leaving the agent without critical information for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage; neither the schema nor the description explains what each parameter (body.name, body.color, path.project_id, path.custom_field_id) means or how they affect behavior. The description adds no semantic value beyond the schema's structure.
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 'Create a custom field option' and includes the HTTP method and path, which makes the action and resource explicit. However, it does not differentiate among the three sibling tools with similar names (weeek_create_a_custom_field_option, _2, _3), so it is not fully distinctive.
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?
There is no guidance on when to use this tool versus alternatives like weeek_create_a_custom_field_option_2 or _3. No context about prerequisites, limitations, or when not to use is provided.
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 provided, and the description only gives the HTTP method and endpoint. Missing behavioral details such as idempotency, errors, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus metadata), but it omits essential details. Not too verbose, but not sufficiently informative.
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?
Given the tool has nested objects and no output schema or annotations, the description lacks completeness. It does not explain response format, error conditions, or any prerequisites for this creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the parameters beyond the endpoint. The agent cannot infer constraints like email format or that organizationId is required.
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 it creates an email via POST to a specific endpoint. However, there is a sibling named 'weeek_create_an_email_2' with no differentiation, leaving ambiguity about which to use.
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 on when to use this tool versus alternatives like 'weeek_create_an_email_2' or when to update instead. No prerequisites or context provided.
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 should disclose behavior but only states the HTTP method and content type. No info on permissions, side effects, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which avoids verbosity, but it lacks structure and front-loads an endpoint string that may be unnecessary for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description leaves the agent without essential context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any parameters. The agent is left with only the schema names and types, which is insufficient for correct usage.
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?
Clearly states 'Create an email' and provides the endpoint, making the action and resource clear. However, it does not differentiate from the sibling tool 'weeek_create_an_email', which likely does the same thing.
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 on when to use this tool versus alternatives. No context about prerequisites, when not to use, or relationships with other 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?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Create an organization' with HTTP method. It does not mention idempotency, side effects, required permissions, or what happens on duplicate names. For a creation 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it omits critical information. It states the endpoint and a basic action but does not include usage notes or parameter hints. It is not optimally structured; it could be more concise if it included essential details. Score reflects minimal viability.
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?
Given the tool's complexity (nested input, no output schema, 0% schema coverage) and lack of annotations, the description is incomplete. It does not describe return values, error conditions, or typical usage patterns. For a creation tool, this is insufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate by explaining parameters. It does not mention the 'body' object or its properties (name, emails, etc.). The agent must rely solely on the schema, which lacks descriptions for each field. This fails to add value beyond the 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 action ('Create an organization') and the resource ('organization'), with the HTTP method and endpoint. It distinguishes from sibling tools like create_a_contact or create_a_deal by specifying the resource type. However, it lacks context about the organizational scope (e.g., workspace), so it's not a perfect 5.
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 on when to use this tool versus alternatives. The sibling list includes many creation tools, but the description does not explain prerequisites, typical use cases, or scenarios where another tool would be better. The agent receives no hints about context.
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 burden. It does not disclose behavioral traits like authentication requirements, side effects (e.g., does it affect timers?), or constraints beyond the endpoint path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but it sacrifices information for brevity. It includes the endpoint and action but lacks explanatory depth.
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?
For a tool with nested objects and required parameters, the description is insufficient. It does not explain the purpose of each parameter or the expected return value, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of parameters (date, userId, duration, isOvertime). The description merely states 'Body: application/json' without any parameter details.
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 action ('Create a time entry') and provides the HTTP method and endpoint. However, it does not distinguish from sibling tools like 'weeek_update_a_time_entry' or 'weeek_delete_a_time_entry', missing differentiation.
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 on when to use this tool versus alternatives such as updating or deleting time entries. The description lacks context about prerequisites or typical use cases.
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 must disclose behavioral traits. It indicates a POST (create) operation but does not mention side effects, authentication needs, idempotency, or any constraints beyond what is implied by the operation. The minimal description adds little beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (13 words) and front-loaded with the HTTP method, but it lacks structure. It is not verbose, but the extreme brevity sacrifices clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is severely incomplete. It does not explain what a board column is, how to use it within the broader API, or what the response looks like. The agent is left with insufficient context to select or invoke the tool correctly compared to many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for the 'name' and 'boardId' parameters. It only says 'Body: application/json', which is already implied by the schema. The agent receives no semantic help for constructing the request body.
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 'Create board column' and includes the HTTP method and endpoint. It's specific enough to differentiate from siblings like 'weeek_update_board_column' but does not explicitly contrast with them.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., requiring an existing board) or exclude any use cases. Siblings like 'weeek_create_board' and 'weeek_update_board_column' remain undifferentiated.
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 provided, so description must disclose behavior. It only mentions HTTP method and content type, omitting idempotency, side effects, or what constitutes successful creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure; front-loads the endpoint but offers no additional layers of detail.
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?
Given the complexity of the schema (nested objects, conditional fields) and no output schema, the description is highly incomplete. It fails to explain required fields, return value, or field-specific requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds no parameter information. The nested schema for config is complex (e.g., number vs boolean types) but entirely unexplained, leaving the agent unable to correctly structure the body.
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 creates a global custom field via POST, but does not differentiate from sibling tools like weeek_create_a_custom_field which likely create project-level custom fields. The purpose is clear but lacks explicit distinction.
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 on when to use this tool versus alternatives (e.g., project-level custom fields). No context on prerequisites or use cases.
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. It only states 'Delete a contact,' implying a destructive operation, but does not disclose whether deletion is reversible, cascading effects, or required permissions. This is insufficient for an AI agent to understand behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes unnecessary 'Tags: Contacts.' It front-loads the HTTP method and action, which is acceptable, but the tag line is extraneous and could be omitted without loss.
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?
Given the simple tool (1 param, no output schema), the description should still explain the required parameter and expected result. It does neither. The agent is left guessing about what happens after deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The input schema shows a required nested 'id' parameter, but the description provides no explanation of the parameter or its format. The agent must rely solely on the schema, which lacks descriptions. The description adds zero value here.
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 verb and resource: 'Delete a contact.' It distinguishes from other delete tools by specifying 'contact', though it doesn't elaborate further. The addition of the HTTP method is redundant but not harmful.
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 provided on when to use this tool versus alternatives like delete_task or delete_project. The description mentions the HTTP method but gives no context for selection.
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 provided, so description must cover behavioral traits. Only states 'Delete a funnel', implying a destructive operation but no details about cascading effects, idempotency, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which makes it concise, but it is under-specified for an agent to use correctly. Could be improved with a brief note on the id parameter.
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?
For a simple delete operation, the description provides minimal context. No output schema is present, and the description does not confirm what happens after deletion. Agent lacks information on how to obtain the funnel id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for parameters. Description adds no meaning for the 'path' object with 'id'. Does not explain that the id is the funnel's identifier, nor its possible types (string or number).
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?
Specifies the verb 'Delete' and resource 'funnel' clearly, matching the tool name. However, it does not differentiate from sibling tools like weeek_delete_a_deal or weeek_delete_a_funnel_status, but the resource is distinct enough.
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 on when to use this tool versus alternatives. Does not mention prerequisites, such as ensuring the funnel has no deals, or that deletion is permanent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., cascading effects, required permissions, or error conditions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it includes the HTTP method and tag. It is not wasteful, but it could be more informative without adding much length.
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?
For a simple delete operation with one parameter, the description is incomplete. It lacks details about the effect of deletion, required permissions, or any caveats. The lack of output schema and annotations compounds the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a nested object with a required 'id', but the description does not explain what the 'id' refers to (presumably the funnel status ID). Since schema description coverage is 0%, the description adds no meaningful guidance beyond the type.
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 'Delete a funnel status', which aligns with the tool name. It also provides the HTTP method and tag, but does not differentiate from sibling tools that delete other entities.
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 on when to use this tool versus alternatives like updating a funnel status or deleting a funnel. The description offers no context about prerequisites or side effects.
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. It only states 'Delete an organization' with no details on destructiveness, idempotency, cascading effects, permissions, or error behavior. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It includes redundant elements like the HTTP method and tags, while omitting essential parameter and usage details. It does not earn its brevity.
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?
Given the simple structure (1 parameter, no output schema), the description is incomplete. It lacks explanation of parameter formatting, prerequisites, or potential errors, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the required 'path' object or the 'id' parameter. It fails to add any meaning beyond the raw schema structure.
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 that the tool deletes an organization, with a specific HTTP endpoint. It is not a tautology and distinguishes from siblings that delete other entities, though it lacks differentiation from similar delete tools.
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 provided on when to use this tool versus alternatives (e.g., archive or update). The description offers no context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description only restates the action. It fails to disclose whether deletion is permanent, permissions required, or any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise but includes an unhelpful 'Tags: Board.' line. The core information is minimal but not verbose.
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?
For a deletion tool with no output schema and no annotations, the description lacks essential context about response, error cases, and prerequisites for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description hints at an 'id' parameter via the URL path but does not explain the path object structure, the format of id, or how to obtain it.
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?
Description clearly states 'Delete board' with the HTTP verb and resource, distinguishing from sibling tools like create_board and update_board.
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 on when to use this tool versus alternatives, no prerequisites, and no warning about cascading effects or irreversibility.
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 burden. It merely states 'Delete board column' without disclosing behavioral traits such as reversibility, permissions, cascading effects, or idempotency. This is insufficient for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant information: the HTTP method and route ('DELETE /tm/board-columns/{id}') are unnecessary for an AI agent. The tag line 'Tags: BoardColumn' adds no value. Could be trimmed to a single sentence.
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?
Given the simple operation and lack of output schema, the description is minimal. It does not explain what a board column is, that it must exist, or how the id relates to other tools. Sibling tools provide some context, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one nested parameter 'id' with zero description coverage in both schema and tool description. The description does not explain what 'id' represents or how to obtain it, providing no value beyond the schema structure.
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 uses the verb 'Delete' and resource 'board column', clearly indicating the action. It distinguishes from siblings like 'create_board_column' and 'update_board_column'. However, it offers no additional context beyond the name and title.
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 provided on when to use this tool versus alternatives such as 'delete_board' or other delete operations. There is no mention of prerequisites like column existence or contents.
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 provide behavioral context. It only says 'Delete', which implies a destructive mutation, but it does not disclose side effects (e.g., whether the field is removed from all tasks), authentication requirements, or irreversibility. This is insufficient for safe agentic use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus a tag), which is concise but lacks necessary detail. It is front-loaded with the endpoint and action, but the brevity comes at the cost of completeness. Every sentence is earned, but more information is needed.
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?
Given the complexity of multiple sibling delete tools, the description does not provide enough context to distinguish this global field deletion from others. No output schema is provided, and the parameter is not explained. The description is incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only one parameter 'path.id', which can be a string or number. The description adds no explanation about what this ID represents (e.g., the custom field identifier). Without this, an agent cannot correctly construct the parameter value.
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 'Delete global custom field' and provides the HTTP method and path. The verb 'Delete' indicates the action and the resource is explicit. However, it does not differentiate from siblings like weeek_delete_a_custom_field, which also delete custom fields but at different scopes.
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 provided on when to use this tool versus alternative delete tools for custom fields. Given many sibling tools with similar names, an agent would need to know that this tool is specifically for global custom fields, but the description does not offer such 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?
Given no annotations, the description should disclose behavioral traits like whether deletion is permanent or soft, required permissions, or cascading effects. It only states 'Delete' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but includes redundant HTTP method and path. It lacks helpful details that could be added without bloating.
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?
For a one-parameter delete tool with no output schema, the description should at least hint at permanence or required authentication. It is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the required 'id' parameter. No additional meaning is provided beyond the empty 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 'Delete portfolio', which is a specific verb and resource. It distinguishes this tool from other delete tools by naming the resource (portfolio). However, it is minimal.
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 provided on when to use this tool vs alternatives like update_portfolio or create_portfolio. The description lacks context about prerequisites or side effects.
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 bears full burden. It only states 'Delete tag' without disclosing behavioral traits such as irreversibility, permission requirements, or effects on associated data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (3 sentences) but includes redundant information: 'Delete tag' and 'Tags: Tags' add little value. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single parameter lacking description, the description fails to provide essential context for correct invocation. It omits return values, side effects, and usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'path.id' parameter. It only shows the path template without clarifying that 'id' is the tag identifier, leaving the agent uninformed.
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 states 'Delete tag' and includes the HTTP method and path, clearly indicating the action and resource. However, it does not distinguish from sibling delete/detach tag tools, which may cause confusion.
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 on when to use this tool versus alternatives like 'weeek_detach_a_tag' or prerequisites. The description lacks explicit usage context.
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 exist, and the description only states 'Delete the phone', implying mutation but lacking details on side effects, idempotency, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes the HTTP method and tags. It is minimally adequate but not structured for easy parsing; every sentence is present but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter descriptions, and no usage context, the description is highly incomplete for a delete operation. Critical information like success behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the parameters (contactsId, phoneId) or how to obtain them, adding no value beyond the schema itself.
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 it deletes a phone from a contact, with the HTTP method and endpoint path. However, it does not differentiate from the sibling tool 'weeek_delete_the_phone', which may cause confusion.
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 on when to use this tool or when not to. No prerequisites or context provided, leaving the agent without decision criteria.
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 traits such as what happens when detaching (e.g., effect on related data, permissions needed, idempotency). The brief description fails to inform the agent of important 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line plus tags), but it is not effectively concise—it omits essential information. It includes technical details (HTTP method, tags) that may be redundant for an agent focused on high-level usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description is severely incomplete. It does not explain the purpose beyond the name, the return value, or any context needed to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, meaning the description adds no explanation of the parameters. The schema includes 'body.contactId' and 'path.dealId', but the description does not explain how to use them, leaving the agent with no guidance beyond the schema types.
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 action ('Detach a contact') and the resource ('from a deal'), with HTTP method and path. However, it does not differentiate from sibling tools like 'weeek_detach_an_assignee' or 'weeek_detach_an_organization', which share similar structure.
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 provided on when to use this tool versus alternatives, no prerequisites, no conditions under which detaching is appropriate. The description merely restates the function without usage context.
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 provided. The description mentions the HTTP method (DELETE) implying destruction, but provides no details on side effects, permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but lacks substance; it essentially repeats the tool name and HTTP method. While not verbose, it fails to add value beyond the structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two nested parameters, no output schema, and zero parameter descriptions, the description is grossly incomplete. It fails to convey necessary context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any parameters. The 'dealId' and 'assigneeId' are not described, leaving the agent with no guidance on what values to provide.
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 'Detach an assignee' with the HTTP method and resource path. However, it does not differentiate from sibling tools like 'weeek_remove_assignee' which might be similar.
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 on when to use this tool versus alternatives such as 'weeek_attach_an_assignee' or 'weeek_remove_assignee'. The description lacks any contextual usage advice.
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 must disclose behavior. It only shows the HTTP method and endpoint, but does not mention side effects (e.g., whether the organization is permanently removed or can be reattached), required permissions, or any destructive actions beyond the DELETE method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence plus endpoint), but this brevity sacrifices crucial information. It lacks structure and does not earn its place by providing sufficient guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and the complexity of two nested object parameters, the description is severely incomplete. It fails to explain the tool's operation, parameter semantics, or usage context, making it minimally helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to the parameters. It only mentions 'Body: application/json' but does not explain the required fields 'organizationId' or 'dealId', leaving the agent to rely solely on the 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 states 'Detach an organization' and includes the endpoint 'DELETE /crm/deals/{dealId}/organizations', clearly indicating it removes an organization from a deal. The verb 'detach' and resource 'organization' are specific, but the context of being from a deal is implied by the endpoint rather than explicitly stated.
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 provided on when to use this tool versus sibling tools like 'weeek_detach_a_contact' or 'weeek_detach_an_assignee'. There is no mention of alternatives, prerequisites, or conditions for use.
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, and the description only states the endpoint and action. It does not disclose whether this operation is destructive, what side effects occur, or any prerequisites (e.g., no mention that the task remains but is just detached from the deal).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines), which is concise but at the expense of useful information. It lacks structure beyond a bare endpoint and tag.
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?
Given no output schema and no annotations, the description should explain return values, error handling, or postconditions. It does none of these, leaving the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the 'path' parameter or its nested 'id' and 'taskId' fields. With 0% schema description coverage, the description adds no value beyond the schema itself.
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 HTTP verb and endpoint, and explicitly says 'Detach a task' and references 'Tags: Deals', indicating the resource. However, it does not explicitly say 'from a deal', which would further distinguish it from similar detach operations.
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 provided on when to use this tool versus other detach tools (e.g., weeek_detach_a_contact, weeek_detach_an_assignee). The description lacks context for selection.
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 carry the behavioral burden. It only says 'Detach the contact' and gives the HTTP method, which implies a destructive operation. It fails to disclose side effects (e.g., whether the contact is actually deleted or just unlinked), authorization needs, or irreversible changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the HTTP method and path, but it includes extraneous info like 'Tags: Organizations' and 'Body: application/json' that could be omitted. It is concise but fails to deliver necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero schema coverage, the description is severely incomplete. It does not clarify what 'detach' entails, the response format, or any error conditions. A tool with nested parameters and destructive effect demands far more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The schema indicates required 'organizationId' and 'contactId' but the description adds no meaning to these fields. The agent must infer from parameter names alone.
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 it performs a DELETE request to detach a contact from an organization. The verb-resource pair is direct: 'Detach the contact' along with the HTTP method and path. However, it does not distinguish from sibling tools like weeek_detach_a_contact, leaving ambiguity.
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 on when to use this tool versus alternatives (e.g., when to use detach vs. delete a contact). There is no mention of prerequisites or context like whether the contact must be attached first.
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 fails to disclose any behavioral traits beyond the basic GET operation. It does not indicate read-only nature, error handling, authentication requirements, or the structure of the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, consisting of a single line. While concise, it sacrifices useful information, making it borderline under-specified for an effective tool definition.
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?
Given the simplicity of a single-deal retrieval, the description is incomplete. It lacks any mention of the response format, possible errors, or relationship to sibling tools, leaving the agent with insufficient context to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no explanation of the 'id' parameter. The agent must infer that 'id' is the deal identifier, but no format or constraints are clarified.
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 a deal' and includes the HTTP method and path, making the purpose evident. However, it does not differentiate from sibling tools like 'weeek_get_all_deals', which could cause confusion.
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 provided on when to use this tool versus alternatives. It lacks information about prerequisites, such as requiring a specific deal ID, and does not mention the appropriate context for single vs. bulk retrieval.
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 burden. It only states 'GET /crm/contacts' implying read-only, but omits behavioral details such as pagination, filtering, sorting, or response format that are crucial for correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but the first sentence is redundant with the tool title, and the tags line adds minimal value. It could be more informative without being longer.
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?
Given the absence of an output schema and the presence of many sibling tools, the description lacks essential context about pagination, filtering, and how it differs from similar tools like weeek_get_a_contact or weeek_get_all_organizations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'query' object with multiple properties (sort, limit, offset, etc.), but the description does not mention any of them. With 0% schema description coverage, the tool description adds no value beyond the 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 HTTP method and endpoint, and indicates that it retrieves all contacts. The tool name itself is descriptive, but the description does not differentiate from sibling tools like weeek_get_a_contact.
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. There is no mention of prerequisites, when not to use it, or how it relates to other contacts-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?
No annotations; description only states it's a GET operation, lacking any behavioral traits (e.g., error handling, permissions, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise but under-informative; front-loads HTTP method but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and description fails to explain response format, errors, or any contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description adds no meaning to the 'attachment_id' parameter beyond the schema structure.
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?
Description clearly states it gets an attachment via GET, but does not differentiate from sibling tools like upload attachments.
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 on when to use this tool vs alternatives. No context on prerequisites 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?
With no annotations, the description carries full burden but only states the operation name and HTTP method. It does not disclose read-only nature, error conditions, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (15 words), which is concise but at the expense of necessary detail. It front-loads the HTTP method and path, but every sentence is minimal.
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?
For a simple tool with one parameter and no output schema, the description should explain how to use the 'id' parameter and what to expect in return. It does not, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 'id' parameter. It only mentions '{id}' in the URL path without explaining what the ID represents. The parameter is completely undocumented in both schema and description.
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 an organization' and provides the HTTP method and path, which unambiguously indicates it retrieves a single organization by ID. It distinguishes from siblings like weeek_get_all_organizations by implication, but does not explicitly differentiate.
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 on when to use this tool instead of others, no prerequisites or exclusions mentioned. The description lacks context for agent selection.
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, and the description only states the HTTP method and endpoint. It does not disclose any behavioral traits like authentication requirements, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it sacrifices completeness for brevity. It is concise but not sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and minimal description, the tool definition is incomplete. It fails to provide expected return format or additional context needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'boardId' parameter. The agent receives no guidance on how to use the parameter, making it likely to misuse or omit it.
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 states 'Get board column list' with a specific verb and resource, clearly indicating the tool retrieves a list of board columns. However, it does not differentiate from sibling tools like 'weeek_get_board_list', which could cause confusion.
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 provided on when to use this tool versus alternatives, such as when to get a single column or modify columns. The description lacks context for selection.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It only states the HTTP method and endpoint, but omits details on pagination, rate limits, authentication requirements, and error responses. The read-only nature is implied but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential information. Conciseness should not sacrifice completeness; here it is under-specified, making it less helpful.
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?
Given the lack of annotations, no output schema, and only partial parameter documentation, the description is insufficient. It does not explain the return structure, pagination behavior, or error handling, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (limit, offset, search, parentId) with 0% description coverage overall. The description does not elaborate on any parameter beyond what is already in the schema (only 'search' has a brief description in the schema). This fails to compensate for the low 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 portfolios' and includes the HTTP method and endpoint, which distinguishes it from the sibling tool 'weeek_get_portfolio' that likely retrieves a single portfolio. However, it could be more explicit about listing multiple portfolios.
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 provided on when to use this tool versus alternatives like 'weeek_get_portfolio' or search-related tools. There is no mention of context or exclusion criteria.
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 provided, so the description must carry full burden. It states 'GET' which implies read-only, but does not explicitly confirm non-destructiveness, authentication needs, or rate limits. The behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but not sufficiently informative. It could include more details without becoming verbose.
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?
For a tool with one parameter and no output schema, the description should clarify the input and what to expect as a response. It only states the purpose and HTTP method, leaving significant gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about the 'id' parameter. The agent is left to infer its meaning and format from the schema alone, which lacks explanatory text.
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 states 'Get project' which clearly identifies the verb and resource. However, it does not explicitly distinguish itself from sibling tools like 'weeek_get_project_list' or 'weeek_update_project_info', though the name and endpoint imply a single project retrieval.
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 on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use it. The description merely repeats the HTTP method and endpoint.
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 only states the HTTP method and basic action. It does not disclose behavioral traits like required permissions, side effects, or return values, which are essential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but lacks structure. It includes technical details like the HTTP endpoint and tags that are already implied by the tool name, and the core purpose is stated in a single sentence without prioritization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, annotations, and parameter documentation, the description fails to provide sufficient context for the agent to understand the tool's full behavior and requirements. The existence of many similar sibling tools further necessitates a more complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. It only mentions 'Body: application/json' without explaining the structure or fields like 'statusId' or 'previousDealId', which are critical for correct invocation.
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 action ('move') and the resource ('a deal within the funnel'), making its purpose understandable. However, it does not differentiate from sibling tools like 'weeek_move_a_attached_to_the_deal_task' or 'weeek_update_a_deal', which have overlapping functionality.
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?
The description provides no guidance on when to use this tool versus alternatives, such as other move or update tools. No explicit context or exclusions are mentioned, leaving the agent to infer usage from the tool name alone.
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 provided. The description only states 'Start task timer' without revealing behavioral details like side effects, prerequisites, or idempotency. Insufficient disclosure for an API call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are efficient, but the description lacks informative content. It is concise but at the expense of necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description omits critical context like what starting the timer entails, impact on existing timers, and required permissions. Incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description does not explain the 'path' parameter, including that 'id' is the task ID. The HTTP path implies it, but no explicit semantics or format guidance is given.
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 'Start task timer' clearly states the action and resource, and distinguishes from siblings like 'weeek_stop_task_timer'. However, it mostly restates the tool name and HTTP path.
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 on when to use this tool versus alternatives, such as the timer-related sibling tools. No exclusions or context provided.
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. Only states 'Transfer custom field to project' without disclosing side effects (e.g., does the field get removed from original location?), permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but under-specified. It front-loads the HTTP endpoint, which is less useful than the functional purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested parameters and no output schema or annotations. The description provides only the bare action, lacking details about constraints, return values, or behavior changes. It is far from complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameters (e.g., board_id, id, projectId) beyond noting 'Body: application/json'. The agent receives no semantic help for the nested required fields.
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 states the action clearly: transfer a custom field to a project. However, it does not differentiate among sibling tools like weeek_transfer_custom_field_to_project or weeek_transfer_custom_field_to_board, all of which have similar names and descriptions.
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 usage guidance provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or limitations.
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 only states the action without revealing side effects (e.g., whether the original custom field is deleted), required permissions, or response format. The HTTP method POST hints at creation but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—a single line with endpoint and a sentence. It is concise but lacks structure or important details. The 'Tags: Board' adds minimal context. It does not waste words, but is too minimal to be well-organized.
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?
Given the absence of annotations and output schema, the description should cover behavior, parameters, and effects. It only mentions the action and endpoint. For a tool that likely modifies board data, this is incomplete and risks misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no explanation of parameters. The endpoint path places {board_id} and {id} are noted, but their meanings are not clarified. The schema defines them as required, but the agent must infer their roles, which is inadequate for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Transfer custom field to task manager' and includes the endpoint path, indicating the action and resource. However, it does not explain what 'transfer' entails (move vs. copy) or distinguish between similar sibling tools like weeek_transfer_custom_field_to_task_manager (without _2). Purpose is clear but ambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for transferring custom fields to different destinations, the agent lacks context for selection. No prerequisites or exclusions are mentioned.
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?
The term 'transfer' suggests moving, but it's unclear if this is a move or copy operation, and no details on side effects, permissions, or reversibility. With no annotations, the description fails to disclose important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), but the first sentence is a raw URL which is not informative. The repetition of the tool name is redundant. Could be more compact while adding substance.
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?
Given no annotations, no output schema, and nested parameters, the description is inadequate. It doesn't explain input format, output, or differentiate from multiple similar transfer tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'Body: application/json' without explaining the path parameter 'id' (the custom field ID) or the body parameter 'boardId' (the target board). It adds no semantic value beyond the raw 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 action ('Transfer global custom field to board') and resource. It specifies the HTTP method and endpoint. However, it does not explicitly differentiate from sibling tools like weeek_transfer_custom_field_to_board or weeek_transfer_global_custom_field_to_project, leaving ambiguity about the distinction between global and non-global fields.
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 on when to use this tool versus alternatives, no prerequisites or exclusions. The description only states the function without context.
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 absent, so the description carries full burden. It only states 'Update a custom field' and includes the HTTP method. It does not disclose mutation behavior, required permissions, rate limits, or any side effects. The input schema suggests possible configuration changes, but the description lacks 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but includes technical details like HTTP method and path that may be redundant. It could be more concise by focusing on functional aspects. The structure is acceptable but not optimized for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (nested objects in schema, multiple possible configurations, no output schema, no annotations), the description is severely incomplete. It fails to explain what the tool does beyond the name, leaving critical gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no property descriptions. The tool description does not add any meaning to the parameters. It only mentions 'Body: application/json' but does not explain the structure or purpose of 'body' or 'path'. This is insufficient for an agent to know what to provide.
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 states 'Update a custom field' which clearly indicates the verb and resource. However, it does not differentiate from sibling tools like weeek_update_a_custom_field_2 or _3, which likely update different scopes (e.g., board-level or global). The HTTP path hints at project-level custom fields, but this is not explicit.
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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling custom field update tools, explicit context for when to choose this specific tool is missing.
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?
The description does not disclose any behavioral traits beyond the basic update action. No annotations are provided, so the description carries the full burden. It fails to mention idempotency, required permissions, side effects, or any constraints. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (single sentence), which is concise but at the expense of essential details. It provides the HTTP method and path but lacks structure (e.g., separate sections for behavior, parameters, examples). The brevity is not effective because it omits key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and the presence of multiple sibling custom field update tools, the description is severely incomplete. It does not explain what can be updated, the response format, error scenarios, or any prerequisites. The agent would struggle to use this tool correctly without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameter descriptions exist. The description adds no information about parameters, such as what 'name', 'config', 'body', or 'path' mean or how to construct them. The agent has to infer from the schema alone, which is complex due to nested objects and conditionals. This is a critical failure.
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 verb (Update) and resource (custom field), and includes the HTTP method and path. It is specific enough to convey the core action, but does not differentiate from sibling tools like weeek_update_a_custom_field and weeek_update_a_custom_field_3, which have identical description text. A score of 4 reflects clear purpose but lacks sibling differentiation.
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 provided on when to use this tool versus alternatives. With multiple sibling tools for updating custom fields, the description offers no context on prerequisites, when not to use it, or what distinguishes it from similar tools. This is a significant gap.
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?
The description only states the action without disclosing behavioral traits. No annotations are provided, so the description fails to convey side effects, idempotency, or requirements such as permissions. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes the HTTP method and path, which are redundant given the tool name. It could be more concise by omitting these details, but overall it is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely incomplete. It does not differentiate from sibling update tools, explain the scope (project vs global), or provide any context about path parameters. Given the complexity of nested parameters and multiple siblings, the description fails to provide sufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning beyond the schema. The schema defines required parameters (name, color) and constraints, but the description does not explain their purpose or any additional context.
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 'Update a custom field option', which is a specific verb+resource. However, it does not distinguish between this tool and sibling tools like weeek_update_a_custom_field_option_2 or _3, which likely update different scopes (e.g., project vs global).
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 on when to use this tool versus alternatives like create or delete options, nor any prerequisites (e.g., existing project, custom field, and option). The description provides no context for appropriate usage.
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 carry full behavioral disclosure. It only says 'Update' implying a write operation, but omits details like idempotency, permissions, error handling, or side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus endpoint), which is efficient but lacks necessary details. It is not verbose, but the brevity comes at the cost of completeness.
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?
Given the complexity (nested objects, multiple IDs) and no output schema, the description is incomplete. It doesn't explain how to obtain funnel_id, custom_field_id, or id, nor the relationship between them. The tool's purpose in the funnel workflow is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning beyond the schema. It does not explain what 'name' or 'color' represent in the context of a custom field option, nor the path parameters. The schema enumerates colors, but the description adds nothing.
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 'Update a custom field option' and provides the HTTP endpoint, making the verb and resource clear. However, it does not differentiate between the multiple update custom field option siblings (option, option_2, option_3).
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 on when to use this tool vs the other update-custom-field-option tools, nor any prerequisites or when not to use it. The description only states what it does without usage context.
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. It discloses the HTTP method and body type but does not explain behavioral traits such as partial vs full update, required permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes technical details like the HTTP method and path, which may be unnecessary for an agent. It is not verbose but could be more focused on the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter documentation, the description is severely incomplete. The agent cannot determine what happens after the update, which fields are modifiable, or how to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds no information about parameters. The path 'id' and body properties are not explained, leaving the agent to infer meaning from names alone.
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 'Update an organization', which specifies the verb and resource. However, it does not differentiate from other update tools like weeek_update_a_contact, relying solely on the resource name.
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 provided on when to use this tool vs alternatives. There is no mention of context, prerequisites, or when to prefer it over create or delete operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states 'Update a task' with no mention of idempotency, partial vs full replacement, side effects, authorization requirements, or error conditions. The input schema contains constraints (e.g., mutual exclusivity of date fields) that are not mentioned in the description, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but lacks essential context. It front-loads the HTTP method and resource but omits usage guidelines, behavior, and parameter hints. For a tool with many parameters and complex constraints, this is under-specified, not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (many optional parameters, nested customFields, date constraints), the description is woefully incomplete. No output schema exists to clarify return values. The description provides no pre-conditions, post-conditions, or examples, leaving the agent to rely solely on the schema, which may not cover all use cases.
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 description adds no information about parameters. However, the input schema itself includes descriptions for several parameters (e.g., dueDate, duration, customFields), providing semantics. According to context, schema description coverage is 0%, but the actual schema contains descriptions; we score based on observed value. The description does not compensate for any gaps, but the schema covers the basics, so a baseline of 3 is appropriate.
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 action ('Update a task') and identifies the resource (task). The HTTP method and path are given. However, it does not differentiate this from other update tools (e.g., weeek_update_a_deal) beyond the resource name, which is adequate but not exemplary.
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 on when to use this tool versus alternatives (e.g., weeek_create_task, weeek_get_one_task_info). No information about prerequisites, required fields, or scenarios where it should not be used. The description is purely declarative.
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?
Without annotations, the description should disclose behaviors like authorization needs or side effects. It only states 'Update board', providing no additional behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant HTTP method/path and a tag. It is concise functionally but lacks informative content, making it minimally acceptable.
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 has a simple schema but no output schema or annotations. The description does not cover expected behavior, error cases, or return values, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the parameters. It neither explains the required 'id' path parameter nor the 'name' field in the body.
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 updates a board and provides the HTTP method and path. However, it does not distinguish this tool from siblings like weeek_update_board_column, which also update board-related resources.
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?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is responsible for disclosing behavior but only states 'Update portfolio'. It does not mention side effects, authentication, error states, or whether the operation is destructive. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but lacks structure. While it includes the HTTP method and endpoint, it is overly sparse and could benefit from clearer sections or bullet points for usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 0% schema coverage, the description is severely incomplete. It fails to explain update behavior, permissible fields, error handling, or return values, making it inadequate for an AI to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the tool description does not explain the parameters at all. It only notes 'Body: application/json' without describing what fields can be updated, leaving the agent without meaningful guidance.
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 'Update portfolio' and includes the HTTP method and endpoint, making the tool's purpose unambiguous. Among siblings like create/delete/get, 'update' is distinct, though no explicit differentiation is stated.
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 provided on when to use this tool vs alternatives, when not to use it, or any prerequisites. The description lacks context for decision-making.
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 provided, so description carries full burden. It mentions HTTP PUT but doesn't disclose destructive nature (e.g., full replace vs partial update), auth needs, or side effects. Agent cannot infer behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but includes redundant HTTP method/path. It is not overly verbose, but lacks substantive content that would earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description is severely incomplete. It does not specify what fields can be updated, the return value, or any constraints like required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no meaning to parameters. It only says 'Body: application/json'. The schema itself provides some detail, but the description fails to explain the role of fields like 'name', 'isPrivate', or the 'id' path parameter.
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 states 'Update project info' which is a specific verb-resource pair. It distinguishes from 'create' and 'get' project tools, but does not differentiate from other update tools like 'weeek_update_board' or 'weeek_update_a_task'.
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 on when to use this tool vs alternatives such as 'weeek_create_project' or other update tools. There is no mention of prerequisites, when not to use, or context for invoking this tool.
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 present, so description must disclose behavioral traits. Only states 'update the address' without revealing if partial update is allowed, authorization needs, or side effects. Schema implies only the 'address' field can be updated, but this is not explicit in description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise but at the expense of necessary detail. The structure mixes technical API details (PUT, tags, content type) with the core action, which may distract an AI agent. Every sentence earns its place, but the content is insufficient.
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?
For a tool with 2 parameters, nested objects, and no output schema, the description is incomplete. Missing explanation of how to obtain organizationId/addressId, constraints on the address field, and what the response contains. Agent would need to infer too much from schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description adds no meaning to parameters. The endpoint string hints at path parameters (organizationId, addressId) but does not explain them. Body parameter 'address' is left as a generic string with no semantic context.
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?
Describes updating an address via PUT, clearly identifying the resource and operation. The endpoint pattern in the description adds specificity. However, includes tangential details (HTTP method, tags) that don't enhance purpose clarity.
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 on when to use this tool versus alternatives like weeek_create_an_address or weeek_delete_the_address. No prerequisites or conditions for invocation are provided.
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 only states a simple update operation but does not reveal if the action is destructive, if permissions are required, or what happens to the previous status. This is insufficient 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the cost of completeness. It is front-loaded with method and path but lacks essential explanatory content. Every sentence does not earn its place because critical information is missing.
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?
Given the tool's moderate complexity (2 parameters, nested objects) and absence of output schema and annotations, the description fails to provide adequate context. It does not explain the purpose of statusId, the effect of the update, or format expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning beyond the schema. It merely mentions 'Body: application/json' without explaining the required fields (e.g., statusId) or the path parameter (id). The agent must guess how to construct the request.
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 verb 'Update' and the resource 'deal funnel status', and includes the HTTP method and path. It is specific enough to distinguish from sibling tools like 'weeek_update_a_deal' which updates deal fields generally. However, it does not explicitly differentiate from 'weeek_update_a_funnel_status' which might update a funnel status definition itself.
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?
The description provides no guidance on when to use this tool versus alternatives such as 'weeek_update_a_deal' or 'weeek_update_a_funnel_status'. It does not specify prerequisites, context, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only implies a read operation via 'GET' and 'Get'. It does not disclose pagination, authentication requirements, or response structure, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences). While brevity is positive, the content is under-specified, repeating the name and adding only the HTTP method. Lacks substantive information.
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?
Given the low complexity and absence of output schema, the description could still provide context about what global custom fields are or how they relate to other tools. It fails to do so, leaving the agent with minimal information.
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 has zero parameters, and schema description coverage is 100%. The description does not need to explain parameters, but it also does not clarify that no parameters are required. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the HTTP method and resource, but does not add any specificity beyond the name and title. It lacks differentiation from sibling tools like create or update global custom fields.
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 on when to use this tool versus alternatives. There are many sibling tools dealing with custom fields, but the description offers no context for selection.
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?
Without annotations, the description should disclose behavioral traits. It only states 'List...' with no details on response format, side effects, or access requirements. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, but too brief to be useful. Lacks structure or front-loading of important details. Under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description fails to explain what is returned or how to use filters. Incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the parameters 'tag' and 'search'. No meaning added beyond the schema, leaving agent to guess their purpose.
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 'generated WEEEK API operations', which is a specific verb+resource. It distinguishes from sibling tools that perform individual actions like create or delete.
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 on when to use this tool versus alternatives, no exclusions or prerequisites mentioned. The description only states what it does, not when or why.
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 provided, so description carries full burden. It discloses only the basic action ('Transfer custom field to board') but fails to mention side effects, permissions, or what happens to the original custom field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short and front-loaded with the endpoint, but lacks structure. It is concise but overly minimal, missing valuable details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and low schema coverage, the description is highly incomplete. It does not explain the transfer process, required parameters, or expected results, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no meaning beyond the endpoint parameters. The body field 'boardId' is not explained, and the description does not clarify how parameters relate to the transfer operation.
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?
Description clearly states 'Transfer custom field to board', which is a specific verb and resource. However, it does not differentiate from sibling tools like 'weeek_transfer_custom_field_to_board' or 'weeek_transfer_custom_field_to_project', so purpose is clear but lacks distinction.
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 on when to use this tool versus alternatives. The description only repeats the action without context for proper selection.
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 carry the burden. It only says 'Add a task to a project' without disclosing behavioral traits like whether the task is moved or appended, what happens if already in a project, or side effects. The schema hints at ordering via 'after' and 'before', but the description does not mention these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) but includes extraneous info like 'Tags: Task' and 'POST /tm/tasks/{task_id}/locations' which may be redundant. It is concise but not well-structured for an agent; it could be more informative in the same space.
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?
Given the complexity (2 parameters, nested objects) and no output schema, the description is incomplete. It does not explain the return value, prerequisites, or the effect of optional parameters like 'boardColumnId'. The agent would lack critical context to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description only states 'Body: application/json' and does not explain what the body or path parameters mean. While the schema itself contains some inline descriptions, the tool description adds no semantic value beyond that.
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 'Add a task to a project', which is a specific verb+resource. However, it does not distinguish from sibling tools like 'weeek_create_task' or 'weeek_remove_a_task_from_a_project', so differentiation is lacking.
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 on when to use this tool versus alternatives. It does not state prerequisites (e.g., task must exist, project must exist) or when not to use it. The usage context is only implied.
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 responsibility for behavioral disclosure. It does not mention side effects, prerequisites, error handling, or whether the operation is reversible. The simple mention of 'POST' implies creation, but no further details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), but it includes the endpoint, verb, and tags. While concise, it sacrifices completeness. It could be more structured with bullet points, but given its brevity, it is not overly verbose.
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?
For a tool with 2 parameters, nested objects, and no output schema, the description is insufficient. It does not explain the relationship between dealId and contactId, nor does it provide context about the operation. The agent would need to guess the inputs and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'Body: application/json', which adds no meaning beyond the schema. The parameters dealId and contactId are not explained, leaving the agent without clarity on their purpose or format.
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 states 'Attach a contact' and provides the endpoint POST /crm/deals/{dealId}/contacts, making the action and resource clear. The 'Tags: Deals' further clarifies context. However, it does not explicitly state that it attaches a contact to a deal, relying on the endpoint structure.
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 on when to use this tool versus sibling tools like weeek_attach_an_organization or weeek_attach_a_tag. The description lacks any when-to-use, when-not-to-use, or alternative suggestions, leaving the agent to infer usage from the name alone.
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 must disclose behavioral traits. It only states 'Attach a new task' and the HTTP method POST, implying creation. However, it fails to mention that the request likely requires a body with task properties (e.g., name), which is critical since the schema only includes a path parameter. No details on return values, permissions, or side effects are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded with the endpoint, which is good for conciseness. However, it omits essential details, making it under-specified rather than appropriately concise. Every sentence should add value; this one adds the endpoint but neglects critical usage instructions.
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?
Given the tool's complexity (1 parameter, no output schema, no annotations), the description is incomplete. It does not explain the full request structure (likely requiring a task body), contrast with other task attach/create tools, or describe the response. An agent would likely fail to invoke this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should add meaning to parameters. The description does not explain the 'path' object or its 'id' property. It merely repeats the endpoint. The agent receives no guidance on what 'id' represents (the deal ID) or that additional body parameters might be needed, leaving the schema's minimal type information unsupplemented.
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 action 'Attach a new task' and provides the endpoint '/crm/deals/{id}/tasks', indicating it attaches a task to a deal. However, it does not distinguish this tool from similar attach tools like 'weeek_attach_a_contact' or 'weeek_add_a_task_to_a_project', which could cause confusion. The purpose is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not specify prerequisites (e.g., deal must exist) or context when 'weeek_create_task' or 'weeek_add_a_task_to_a_project' would be more appropriate. There is no exclusionary language or mention of alternatives.
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 only states 'Attach an organization' and the HTTP method, omitting side effects (e.g., whether prior attachments are replaced), idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but at the cost of completeness. It front-loads the endpoint but lacks essential information, making it minimally acceptable.
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?
Given the lack of annotations, output schema, and sibling differentiation, the description falls short. It does not explain prerequisites, return value, or behavior when the organization is already attached, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no details about the path (dealId) or body (organizationId) parameters. The agent must infer meaning solely from parameter names, which is insufficient.
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 'Attach an organization' and the endpoint '/crm/deals/{dealId}/organizations' clarify that the tool attaches an organization to a deal. This is more specific than a tautology, but it does not distinguish from sibling attach tools (e.g., attach a contact) beyond the entity type being attached.
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 provided on when to use this tool versus alternatives like attaching a contact or assignee, nor when not to use it. The agent receives no contextual cues for selection.
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 burden. It does not disclose behavioral traits such as idempotency, error handling, or what happens if the tag already exists. The minimal description fails to inform the agent about side effects or requirements.
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 concise with three short sentences. It includes the essential information but could be more detailed without being verbose. The structure is clear but lacks parameter explanation.
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 description is incomplete for a tool with nested parameters and no output schema. It fails to specify the entity to which the tag is attached (though implied by endpoint) and does not explain the response or potential errors. Among many sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. It only mentions 'Body: application/json' but does not describe the 'tag' integer field or the 'dealId' path parameter. The agent has no context on what values to provide or their meaning.
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 action (Attach a tag) and the resource (crm/deals/{dealId}/tags). It specifies the HTTP method and body format. However, it does not differentiate from sibling tools like weeek_attach_a_tag_2 and weeek_attach_a_tag_3, which likely attach tags to different entities.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context for when attaching a tag is appropriate.
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 only states the action, omitting critical details like whether the operation is destructive, required permissions, or side effects on the task.
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 very concise and front-loaded, stating the HTTP method, endpoint, and action in one sentence. However, it includes redundant information from the tool name and schema.
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?
Given the lack of output schema and parameter descriptions, the tool is inadequately documented. The agent lacks necessary context about required inputs and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation of the 'boardColumnId' or 'id' parameters. This leaves the agent without meaning beyond the schema types, which is insufficient for correct invocation.
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 'Change board column' with the endpoint, indicating it modifies the board column of a task. However, it does not differentiate from similar sibling tools like weeek_move_board_column or weeek_change_board, limiting clarity about specific use.
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 on when to use this tool versus alternatives. The description lacks context about prerequisites, when not to use it, or how it compares to similar tools for moving tasks or boards.
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. It only mentions the HTTP method and content type, omitting critical behavioral details such as required permissions, side effects (e.g., irreversible creation), or error conditions. The agent cannot infer safety or constraints.
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 very short at only three clauses, making it easy to scan. However, it sacrifices substance for brevity; for a tool with complex parameters, more front-loaded detail would be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, multiple enum-dependent configs) and lack of output schema, the description is severely incomplete. It fails to explain the return value, error handling, or the relationship between parameters like type and config, which are critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what is in the schema. Although the schema includes some inline notes (e.g., 'Required if type = currency'), the description itself does not explain the meaning of parameters or their relationships, leaving the agent to parse a complex nested schema with 0% description 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 the tool creates a custom field and provides the exact HTTP method and endpoint (POST /crm/funnels/{funnel_id}/custom-fields). However, it does not differentiate from sibling tools like weeek_create_a_custom_field_1 or weeek_create_a_custom_field_2, leaving ambiguity about when to use this specific variant.
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 provided on when to use this tool versus alternatives, nor are there any prerequisites, such as requiring a funnel to exist. The description lacks exclusions or context for appropriate usage.
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 provided, so the description must disclose behavior. It only mentions HTTP method and tags, omitting details like idempotency, authorization needs, or side effects. The name implies creation, but no further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one line) but lacks structure. It includes the HTTP path, action, tags, and body type, but is too brief to be truly helpful. It is concise but under-informative.
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?
Given no annotations, no output schema, and two nested parameters, the description is incomplete. It doesn't explain return values, required permissions, or constraints (e.g., uniqueness of option name). The agent lacks sufficient context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond what the schema provides. It fails to explain parameter purpose, constraints, or relationships, leaving the agent to infer from the schema alone.
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 title and description clearly state the action (create) and resource (custom field option). However, it does not differentiate from sibling tools 'weeek_create_a_custom_field_option' and 'weeek_create_a_custom_field_option_3', which likely have similar purposes.
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 on when to use this tool versus alternatives. The description lacks context about prerequisites or scenarios where this tool is appropriate, making it hard for an AI agent to decide.
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 provided, so the description must convey behavioral traits. It merely states it's a POST request and creates a deal, but omits side effects (e.g., data mutation), permission requirements, rate limits, or return behavior. The phrase 'Body: application/json' is technical but not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence plus endpoint info, but this comes at the cost of missing necessary guidance. The structure is front-loaded with the action, but every word could earn its place if more content were included. It is not verbose, but under-specified.
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?
Given the lack of annotations and output schema, the description should provide a fuller picture. The complex input schema with nested objects and custom fields requires more explanation. No details on what a deal is, how statusId works, or what the response contains make the tool hard to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has many properties (tags, title, amount, etc.) with 0% schema description coverage. The tool description adds no parameter explanation, leaving the agent to infer from property names alone. The only parameter context is the customFields description in the schema, not in the tool description.
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 action ('Create a deal') and the resource ('/crm/statuses/{statusId}/deals'), making the purpose evident. However, it does not distinguish this tool from siblings like 'weeek_update_a_deal' or 'weeek_get_a_deal', missing a chance to differentiate.
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 on when to use this tool versus alternatives, such as when to create vs. update a deal. Also lacks prerequisites (e.g., need an existing status ID) or context about typical use cases.
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 burden. It only mentions the HTTP method and tag, but fails to disclose that this is a mutation that creates a new phone record, potential idempotency issues, or required permissions. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus tags), but this conciseness sacrifices clarity and completeness. It is not front-loaded with the most critical information for selection.
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?
Given the simple tool and many siblings, the description is incomplete: it doesn't explain the role of contactsId, the expected return, or how it differs from weeek_create_a_phone. No output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds no parameter details (e.g., format of phone, requirement of contactsId). It only says 'Body: application/json' which adds technical context but not meaning beyond schema structure.
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 'Create a phone' and provides the endpoint, indicating it creates a phone resource associated with a contact. The verb and resource are specific, but it doesn't differentiate from the sibling tool weeek_create_a_phone.
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 like weeek_create_a_phone or weeek_update_the_phone_2. The context of needing a valid contactsId is implied but not 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 present, so the description must disclose behavioral traits. It only states 'Create board', which is minimal. It does not mention that this is a write operation that requires a projectId, nor any side effects, permissions, or limitations. The description adds little 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it lacks structure. It is not front-loaded with the most important information, and it does not earn its keep by providing much value beyond the tool name. A single sentence is acceptable if comprehensive, but here it is insufficient.
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?
Given the low complexity (1 parameter, no output schema, no annotations), the description is still incomplete. It does not explain what creating a board entails, what the response looks like, or how it fits into the larger system. The agent would need to infer much from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes property descriptions for 'name' and 'projectId', so the base coverage is provided. However, the tool description does not add any additional meaning or advice about these parameters. It doesn't explain how to use the body object or any constraints beyond what is in the 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 verb 'Create' and the resource 'board', and includes the HTTP method and endpoint. It is straightforward, but does not differentiate from other create tools like 'weeek_create_project' or 'weeek_create_board_column'. However, the name itself is specific enough to avoid confusion.
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 guidelines are provided about when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The agent is left without guidance on whether this is the right tool for a given scenario.
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. It only states the endpoint and body type ('application/json'), but does not disclose any behavioral traits such as whether the operation is idempotent, what happens on success, or any side effects. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it misses critical information. While it is concise, it is under-specified for practical use. The front-loading is minimal; it could be improved by adding parameter hints or usage context.
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?
Given two parameters with nested objects, no output schema, and no annotations, the description is incomplete. It does not explain the return value, how to construct the 'path' object, or how the 'color' choices affect the option. The agent would need to rely solely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description adds no meaning beyond the schema. It does not explain the purpose of the 'body' or 'path' parameters, nor does it clarify the color enum or the required 'name' field. The agent must infer everything from the 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 action ('Create global custom field option') and provides the HTTP endpoint. The title and name align with the tool's function, and the inclusion of 'global' helps differentiate it from similar custom field option tools. However, it does not explicitly distinguish from siblings like 'weeek_create_a_custom_field_option'.
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, or any prerequisites. There is no mention of when not to use it, such as for non-global custom fields or for updating options.
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 fully convey behavioral traits. It only states 'POST /tm/tasks. Create task. Body: application/json.' This lacks details on side effects, required parameters (e.g., 'locations' is required but not mentioned), error handling, or return values. Minimal transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence). While brevity is good, it sacrifices necessary detail. It is front-loaded with the HTTP method and endpoint, but lacks sufficient information to be fully useful. Score reflects under-specification rather than efficient conciseness.
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?
Given the complexity of the input schema (nested objects, required fields) and the large number of sibling tools, the description is very incomplete. No output schema exists, and the description fails to differentiate from similar tools or explain key parameters. Essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no explanation of parameters. The input schema is complex with nested objects (e.g., 'locations' requiring 'projectId' and 'boardColumnId'), yet the description provides no guidance on how to structure the body. The single parameter 'body' is not elaborated.
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 states 'Create task' clearly, indicating the tool's action and resource. However, it does not differentiate from sibling tools like 'weeek_add_a_task_to_a_project' or 'weeek_attach_a_new_task', which may also create tasks in different contexts. The purpose is clear but not unique.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or context. This leaves an AI agent without guidance on tool selection.
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?
The description implies destruction via 'DELETE' but does not disclose irreversibility, side effects, or authentication needs. Without annotations, more detail is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant HTTP path information. It could be more concise by omitting the path and focusing on usage context.
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?
Given the presence of sibling deletion tools and no output schema, the description fails to provide sufficient context about effects, undoability, or scope. It lacks completeness for a deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (path) with nested properties (project_id, id), but schema description coverage is 0%. The description does not explain these parameters beyond stating the action, so it adds negligible value.
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 'Delete a custom field' and includes the HTTP method and path, providing a clear verb+resource. However, it does not distinguish between this tool and siblings like weeek_delete_a_custom_field_2 and _3.
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 the alternatives. The description lacks any context about prerequisites, scenarios, 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?
The description implies deletion (a destructive action) but does not disclose any side effects, access requirements, or reversibility. With no annotations, the description must provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it could include more useful information without becoming verbose. The structure is minimal but acceptable.
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?
Given the lack of output schema and 0% schema description coverage, the description is insufficient. It does not explain what happens after deletion (e.g., response) or any constraints on the custom field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The parameter 'path' contains board_id and id, but the description only repeats the URL pattern without explaining what these identifiers represent or where to find them.
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 'Delete a custom field' and includes the HTTP method and URL, making the action obvious. However, it does not differentiate from sibling tools weeek_delete_a_custom_field and weeek_delete_a_custom_field_3, which likely have identical descriptions.
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 provided on when to use this tool versus alternatives (e.g., when to choose this over other delete custom field tools). There are no prerequisites or exclusions mentioned.
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?
The description only states 'Delete a custom field' and 'Tags: Funnels', with no annotations to rely on. It fails to disclose behavioral traits such as whether the deletion is permanent, reversible, or has side effects on related data. A deletion operation demands more transparency than provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the HTTP path, but it is under-stuffed for the information needed. Every sentence should earn its place; here, 'Tags: Funnels' adds minimal 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?
Given the tool complexity (deletion, multiple similar siblings, nested parameters), the description is inadequate. It does not explain how this tool differs from other delete custom field tools, nor does it mention return values or side effects. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaningful explanation for the parameters (funnel_id, id). It mentions them in the path but does not clarify their purpose, accepted values, or constraints. The schema's type definitions (string or number) are not supplemented.
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 'Delete a custom field' and includes the HTTP method and path, reinforcing the deletion purpose. However, it does not distinguish this tool from sibling delete custom field tools (weeek_delete_a_custom_field, weeek_delete_a_custom_field_2), lacking specificity on what makes this variant unique (e.g., context, scope).
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 provided on when to use this tool versus the other delete custom field tools or other sibling tools. There is no mention of prerequisites, alternatives, or exclusions, leaving the agent without context to choose appropriately.
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 provided. Description merely repeats the delete action and HTTP method, adding no behavioral insights (e.g., side effects, permissions, reversibility).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but at the cost of missing critical information. The HTTP path is redundant with the tool name, and 'Tags: Board' is minimal context.
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?
Given no output schema and no annotations, the description fails to inform about return values, error handling, or parameter details, making it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description does not explain the three required path parameters (project_id, custom_field_id, id) beyond what the name implies.
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?
Description clearly states 'Delete a custom field option' with HTTP path, indicating a delete action. However, among siblings weeek_delete_a_custom_field_option, _2, and _3, there is no differentiation.
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 on when to use this tool versus alternatives (e.g., the other two delete option tools). No prerequisites or context provided.
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?
The description only says 'Delete a deal', implying permanent removal, but does not disclose if the action is reversible, what side effects occur (e.g., cascading deletes), or any authorization requirements. With no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, which is good for brevity, but it sacrifices necessary information. It is front-loaded with the endpoint, but the content is too sparse.
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?
Given the tool's complexity (delete action with a nested object parameter, no output schema, no annotations), the description fails to provide important context such as return values, error behavior, or the effect on associated data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'id' is only implied by the endpoint path, but the description does not explain what it represents or its expected format. Schema coverage is 0%, so the description should clarify the parameter, but it does not.
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 verb 'Delete' and the resource 'a deal', and includes the HTTP method and endpoint. However, it does not differentiate from other sibling delete tools beyond the name, which is already distinctive.
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 provided on when to use this tool versus alternatives, such as other delete operations or update tools. There is no mention of prerequisites, consequences, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. The description does not disclose that deletion is permanent, whether it requires permissions, cascading effects on tasks, or recovery options. Entire behavioral burden is unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one line) but front-loads the HTTP method. However, 'Delete project' is redundant with the name. Could be more efficient by omitting redundancy.
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?
No output schema and minimal description. Fails to provide enough context about the operation, parameters, or expected behavior for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain the 'id' parameter or its type (project ID). Merely echoing the endpoint pattern without adding clarity.
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?
States 'Delete project' and includes the HTTP method (DELETE) and endpoint pattern, clearly indicating the resource and action. Distinguishes from siblings like 'archive_project' by the delete verb.
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 on when to use this tool versus alternatives like 'weeek_archive_project'. No prerequisites, consequences, or context for use provided.
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 provided, so description must disclose behavioral traits. It only says 'Delete the email' without mentioning side effects, required permissions, reversibility, or related data impacts. Agents need more detail for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes the HTTP method and path, which is useful. However, it could be more concise by omitting redundancy with the title, but overall it's efficient.
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?
Given the lack of output schema, annotations, and parameter descriptions, the description is incomplete. It does not explain how to construct the request, what happens upon success, or error scenarios. A minimal delete operation still requires more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no explanation of the parameters. The path parameter with nested contactId and emailId is not described, leaving agents to guess their roles and formats.
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?
Description states 'Delete the email' and includes the HTTP path, clearly identifying the resource. However, it repeats the title without adding differentiation from sibling delete tools like weeek_delete_the_address or weeek_delete_the_phone, although the path specifies 'emails'.
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 on when to use this tool versus alternatives such as weeek_update_the_email_2 or other delete tools. Agents are left to infer context from the resource path alone.
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 only says 'Get a contact'. It does not disclose whether this is a read-only operation, any required permissions, or what happens on error. The GET method implies safety but is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant HTTP path and a 'Tags: Contacts.' line that adds minimal value. It is not bloated, but could be more informative without losing conciseness.
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?
Given no output schema and low schema coverage, the description is insufficient. It does not mention return format, prerequisites, or how this relates to other contact tools. For a tool with many siblings, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of the 'id' parameter beyond its presence in the path. The nested 'path' object structure is not clarified, leaving the agent to infer meaning from the tool name.
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 a contact' which identifies the verb and resource. The HTTP path is extra but not misleading. It distinguishes from 'weeek_get_all_contacts' by implying single contact retrieval, though it could be more explicit.
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 on when to use this tool vs alternatives like 'weeek_get_all_contacts', 'weeek_update_a_contact', or 'weeek_delete_a_contact'. The description lacks any context for selection.
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 fully convey behavior. It only states it's a GET request and retrieves a funnel, but omits any details about side effects, permissions, rate limits, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant information (the path and the statement 'Get a funnel' are repetitive). It could be more efficient while remaining clear.
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?
With no output schema and no description of what a funnel is or what fields are returned, the description lacks completeness. For a retrieval tool, it should specify the structure or content of the returned object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the 'id' parameter beyond being part of the URL path. The agent must infer that 'id' refers to a funnel ID from the context, which is insufficient.
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 a funnel' and includes the HTTP method and endpoint path. It distinguishes from sibling tools like 'weeek_get_all_funnels' and 'weeek_get_a_funnel_status', indicating a specific retrieval operation.
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 provided on when to use this tool versus alternatives (e.g., when to use this vs. 'weeek_get_all_funnels'). There are no prerequisites or context about when to invoke it.
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?
The description is extremely brief and does not disclose any behavioral traits beyond the fact that it's a GET request. Since no annotations are provided, the description should explain it's read-only, but it doesn't. It also doesn't mention authentication, error handling, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and efficient, but lacks substantive information. It is not overly verbose, but could be improved without adding length by including key details.
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 has no output schema, so the description should explain what is returned. It does not mention return type or structure. Given the complexity of a CRM funnel status, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the parameter only implicitly via the URL path ('{id}'), but does not explain the 'path' object parameter or what the id represents. With 0% schema coverage, the description adds minimal value beyond the parameter name.
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 a funnel status' and includes the HTTP method and endpoint, making it easy to understand the action. It distinguishes from sibling tools like create, delete, update, and list all funnel statuses.
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?
The description provides no guidance on when to use this tool versus alternatives like get_all_funnel_statuses. There is no context for prerequisites, use cases, 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 provided, so description should cover behavioral aspects. It merely says 'Get all deals' without mentioning pagination, sorting, rate limits, or authentication. Schema has some parameters but description adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but front-loads the HTTP method and purpose. However, it is under-specified and could include more useful details without being verbose.
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?
Given no annotations and no output schema, the description lacks context about deal statuses, result structure, and relationship to other entities. It is insufficient for a complex tool with many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no information about parameters beyond the schema, which has partial descriptions (e.g., sort, limit). For parameters like 'statusId' or 'tags', no extra context is provided.
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 it retrieves deals via GET endpoint and mentions the resource 'all deals'. It distinguishes from siblings like 'weeek_get_a_deal' which retrieves a single deal.
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 on when to use this tool vs alternatives like 'weeek_get_a_deal' or other list tools. No prerequisites or exclusions mentioned.
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 carries the full burden. It only mentions the HTTP method and endpoint, omitting side effects, permissions, or constraints (e.g., the mutual exclusivity of 'after' and 'before' is not stated). The description is insufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes extraneous elements like 'Tags: Board' and 'Body: application/json' that add little value. It is not front-loaded with the most critical information and could be more structured.
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?
Given no output schema, no annotations, and only two parameters with minimal description, the tool definition is incomplete. The agent lacks information about return values, error conditions, or the effect of the move operation, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having descriptions for 'after' and 'before', the description adds no extra meaning. It does not explain the path parameters (board_id, custom_field_id, id) or clarify the relationship between 'after' and 'before'. With 0% schema description coverage (as per context), the description fails to compensate.
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 'Move a custom field option' and includes the HTTP method and endpoint. However, it does not differentiate from sibling tools like weeek_move_a_custom_field_option and weeek_move_a_custom_field_option_3, which have identical titles and descriptions.
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 provided on when to use this tool versus alternatives. There are multiple similar sibling tools (e.g., weeek_move_a_custom_field_option, weeek_move_a_custom_field_option_3) with no distinguishing context, leaving the agent without decision criteria.
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 exist. The description does not disclose any behavioral traits such as whether the move is destructive, reversible, or requires specific permissions. It only states the action without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a verbose endpoint URL that may not be helpful for an AI agent. It is concise but could be more effective by summarizing key constraints instead of duplicating the HTTP method and path.
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?
Given no output schema, no annotations, and two nested objects with required fields, the description is incomplete. It omits crucial details like the need to provide either after or before, and the effect of the move on the option order.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fails to explain the required parameters (funnel_id, custom_field_id, id, after, before) or the constraint that after and before are mutually exclusive. The schema has descriptions for body properties, but the description adds nothing.
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 states 'Move a custom field option,' which clearly indicates the verb and resource. However, it does not differentiate from sibling tools like weeek_move_a_custom_field_option or weeek_move_a_custom_field_option_2, leaving the agent unsure which variant to use.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, when-not to use, or context for the move operation.
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 cover behavioral traits. It only states 'DELETE' and 'Remove', but does not disclose what happens if no watchers exist, authorization requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three sentences) but includes HTTP method and tag. It is not verbose but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, zero schema coverage, and no annotations, the description provides insufficient context for an agent to safely use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'body' or 'path' parameters, leaving the agent to infer from the schema alone which is incomplete.
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 'Remove watchers from a task' with a specific verb and resource, distinguishing it from sibling tools like 'add watchers' or 'remove assignee'.
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 provided on when to use this tool or when not to, nor are alternatives or prerequisites mentioned.
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 convey behavioral traits. It states the HTTP method (PUT) and content type, implying a modification, but does not disclose side effects, permissions required, idempotency, error conditions, or the fact that name and color are the only updatable fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the HTTP path, which is efficient. However, it lacks sufficient substance to be genuinely helpful, conveying only the bare minimum. It is not overly verbose but also not earning its place with valuable content.
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?
Given the complexity of the input schema (nested objects, required fields, enums) and no output schema, the description is insufficient. It does not explain the purpose of the path IDs, the allowed values for color (though present in schema, the description should summarize), or the behavior of updating. The tool is one of many similar update tools, and more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to parameters beyond the schema. The description only mentions 'Body: application/json' but does not describe the required 'name' and 'color' fields in the body or the path parameters. With a complex nested schema, the description should have provided a high-level overview of the parameters.
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?
Clear verb 'Update' and resource 'custom field option' are stated. The HTTP path and method are provided, making the operation unambiguous. However, no differentiation from sibling tools like 'weeek_update_a_custom_field_option' or 'weeek_update_a_custom_field_option_3' is given.
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 on when to use this tool versus alternatives. There are multiple update tools for custom field options (e.g., without '_2', with '_3'), but the description does not explain the difference or provide selection criteria.
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 does not mention side effects, authentication needs, idempotency (though PUT implies it), or error handling. The agent is left to infer behavior from the HTTP method alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line), but it includes raw HTTP method and path information that could be considered noise. While not wasteful, it could be restructured to prioritize the action over technical details.
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?
Given the tool's complexity (nested objects in schema, no output schema), the description is far from complete. It does not explain that the funnel is identified by ID, what fields are updatable, or the expected response. Basic context for a CRUD update is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no explanation of parameters beyond 'Body: application/json'. It fails to compensate for the schema's lack of descriptions for most parameters (though isPrivate has a brief note). The agent must interpret schema structure without semantic aid.
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 action ('Update a funnel') and resource (funnel), distinguishing it from sibling tools like 'create_a_funnel' or 'delete_a_funnel'. The inclusion of the HTTP method and path adds specificity, though somewhat technical.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or context. The agent receives no guidance on decision-making.
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 provided, so description carries full burden. It fails to disclose behavioral traits like idempotency, side effects, required permissions, or error handling. Only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus tags) but lacks essential details. It could be improved by removing the redundant 'Tags' line and adding parameter clarification.
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?
With no annotations, no output schema, and 0% schema coverage, the description is severely incomplete. It does not tell the agent how to construct the request or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It does not mention the 'id' path parameter or the optional 'name' in the body. No value contexts are provided beyond the schema structure.
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 states 'Update a funnel status' with HTTP method and path, clearly indicating the action. It distinguishes from siblings like create/delete/get funnel statuses. However, the inclusion of 'Tags: Funnel Statuses' is redundant with the title.
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 on when to use this tool vs alternatives. There is no mention of prerequisites, conditions, or when not to use it. Sibling tools exist but no differentiation provided.
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?
The description is minimal and does not disclose any behavioral traits beyond the basic update action. No annotations are provided, so the description carries the full burden. It does not mention side effects, authentication requirements, error conditions, or what happens if the entry does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it lacks important details. It is concise in length but not in completeness, as it omits necessary context. The front-loading is acceptable (action and endpoint first).
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?
Given the complexity of two nested objects in the input schema and no output schema, the description is incomplete. It does not explain the expected behavior, return values, or how the update affects the resource. The presence of sibling create/delete tools without differentiation further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. It only mentions 'Body: application/json' but does not explain any parameters. The schema itself provides descriptions for some properties (date, duration, isOvertime), but with 0% schema description coverage reported, the description fails to compensate for any gaps.
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 verb 'Update' and the resource 'a time entry', and includes the HTTP method and endpoint. This distinguishes it from related sibling tools like create and delete time entries. However, it does not elaborate on what specific fields can be updated, which would further clarify purpose.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. The description only explains what it does without any usage context.
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?
The description only states "Update" without specifying which attributes can be changed (name, config), what happens to omitted fields, or whether the operation is idempotent. No annotations are provided to mitigate these gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but omits valuable information. It front-loads the HTTP method and path, which may be redundant for agents familiar with REST APIs, but overall lacks substance.
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?
Given the complexity of the input schema (nested objects, conditional fields) and the lack of output schema or annotations, the description fails to provide enough context for an agent to confidently invoke the tool. No information about response format or side effects is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the tool description adds no explanation for parameters. Although the schema itself contains some inline hints (e.g., "Required if type = currency"), the description does not clarify parameter meaning or usage beyond the 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 states "Update global custom field" with the HTTP method and path, clearly identifying the action and resource type. It distinguishes from sibling tools like create, delete, or get for global custom fields.
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 provided on when to use this tool versus alternatives like transfer_global_custom_field_to_board or update_global_custom_field_option. There is no mention of prerequisites or contextual use cases.
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?
The description provides minimal behavioral information beyond the HTTP method and resource path. It does not disclose idempotency, required permissions, error behavior, or response format. With no annotations, the description carries the full burden, and it fails to convey important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant technical details like the HTTP method and path, which are already implied by the tool name. It could be more concise by focusing on the action and behavior rather than restating the endpoint.
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?
Given the lack of annotations, output schema, and parameter descriptions, the description is insufficient. It does not explain the return value, error conditions, or validation rules, leaving significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The body.email field and path parameters are not explained, leaving the agent to infer their semantics from the schema alone. The description does not compensate for the lack of parameter descriptions.
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 that the tool updates an email resource, specifying the HTTP method and resource path with placeholders for organizationId and emailId. It distinguishes from siblings like create and delete, but does not specify which fields can be updated beyond the email string in the body.
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 on when to use this tool versus alternative email update tools (e.g., weeek_update_the_email_2) or prerequisites such as the email existing. The description lacks context on appropriate usage scenarios.
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 provided. Description does not disclose behavioral traits such as whether it overwrites the existing phone, requires specific permissions, or any side effects. The verb 'update' implies mutation, but no additional context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes the HTTP method and tags, which is useful but not structured optimally. It lacks critical information about request structure and constraints.
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?
Given no output schema, no annotations, and nested required parameters, the description is incomplete. It fails to explain how to construct the request (e.g., that path and body are required) or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameters; it only mentions 'Body: application/json'. The agent must infer from the schema that 'path' requires contactsId and phoneId, and 'body' requires a phone string. This adds little value beyond the 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 it updates a phone and includes the endpoint path, which specifies it's for a contact's phone. It distinguishes from create/delete siblings by using 'update'. However, it does not explicitly state that it updates the phone number specifically, leaving slight ambiguity.
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 on when to use this tool versus create, delete, or other update tools. It does not mention prerequisites or contextual clues for when to invoke this tool over alternatives.
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?
The description fails to disclose behavioral traits such as error handling, file size limits, overwrite behavior, or authentication requirements. With no annotations, the description carries the full burden but provides minimal insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks important details; it is concise but under-informative. The structure is minimal, providing only the HTTP method and endpoint without elaboration.
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?
Given no output schema and nested parameters, the description fails to explain return values, error responses, or practical usage. It is incomplete for a tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter explanations beyond the raw schema. While the schema includes some descriptions for nested properties, the tool description does not clarify parameter usage or constraints.
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 states 'Upload attachments' and includes the endpoint for deals, making it clear the tool attaches files to a deal. However, it does not differentiate from the sibling 'weeek_upload_attachments', leaving ambiguity about which variant to use.
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 provided on when to use this tool versus alternatives like other attachment tools. The description lacks context for effective tool selection.
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 but only states 'Create a custom field' without disclosing side effects, permissions, limits, or idempotency.
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 short and to the point, with the HTTP method and path front-loaded. It contains no unnecessary words, though 'Tags: Project' is ambiguous.
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?
Given the complex nested schema and lack of output schema, the description is insufficient. It does not explain the config options or required fields, nor does it differentiate from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no information about parameters beyond 'Body: application/json'. The nested config and type constraints are not explained.
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 creates a custom field and includes the HTTP method and path. However, it does not distinguish this tool from similar siblings like create_a_custom_field_2 or create_global_custom_field.
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 provided on when to use this tool versus alternatives. The description does not mention any prerequisites or context for selection.
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 exist, and the description fails to disclose behavioral traits. It does not mention whether the operation is destructive, idempotent, or what side effects occur (e.g., whether duplicate names are allowed). Minimal transparency.
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 very concise (two sentences) and includes the HTTP method, endpoint, and tags. It is front-loaded but lacks structure for usage context. Could be improved by adding a short usage note.
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?
Given no output schema and low parameter coverage, the description is incomplete. It does not explain what the response returns, any constraints (e.g., uniqueness of status names), or how this tool fits among many sibling funnel-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not add any explanation of parameters. It only mentions 'Body: application/json' without describing required fields or the meaning of 'name' or 'funnelId'. The agent must rely solely on the schema, which has no descriptions.
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 HTTP method and endpoint, and confirms that it creates a funnel status. It is specific about the resource and action, but does not differentiate from sibling tools like weeek_update_a_funnel_status or weeek_get_a_funnel_status.
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 provided on when to use this tool or when to avoid it. There are no exclusions, prerequisites, or alternatives mentioned. The agent receives no context for decision-making.
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 convey behavioral traits. It only says 'Create an address' without mentioning side effects, idempotency, or auth requirements. It is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it lacks necessary detail. It is not overly verbose, but it is under-specified.
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?
With no output schema, no annotations, and incomplete parameter information, the description fails to provide a complete understanding of the tool's behavior and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description does not explain the parameters (address, organizationId) beyond what's in the schema, which is minimal. The agent cannot infer how to construct valid inputs.
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 an address') and the resource, and the full list of sibling tools includes update and delete for addresses, helping distinguish it.
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 on when to use this tool versus alternatives like weeek_update_the_address. No prerequisites or context are provided.
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 exist, so the description must disclose behavior. It only says 'Create portfolio' but does not explain side effects, permissions, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but omits crucial details. While concise, it sacrifices informative content, resulting in minimal utility.
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?
With no output schema and no annotations, the description fails to explain the return value or behavior. It does not cover what the tool produces (e.g., created portfolio object, ID).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the schema. It does not explain the 'name' or 'parentId' fields, leaving the agent without necessary context.
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 HTTP method, endpoint, and action ('Create portfolio'), making it unambiguous. It distinguishes from sibling tools like weeek_get_portfolios and weeek_delete_portfolio.
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 on when to use this tool versus alternatives (e.g., when to create vs update vs get). No prerequisites or context provided.
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 but only states basic facts (HTTP POST, JSON body). It does not disclose side effects, authentication requirements, idempotency, or error behavior.
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 very short and front-loaded with key information (HTTP method and path). However, it could be more informative without significant length increase.
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?
Given the complexity (nested object, no output schema, no annotations), the description is insufficient. It lacks details on response, required fields, and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation of the parameters or their meaning. Only 'Body: application/json' is mentioned, which is already obvious from the 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 'Create project' and provides the HTTP method and path (POST /tm/projects). However, it does not explicitly differentiate from related sibling tools like 'weeek_update_project_info' or 'weeek_archive_project'.
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 provided on when to use this tool versus alternatives. It lacks context on prerequisites, when not to use, or typical scenarios.
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 provided, so description carries full burden. Only states 'Delete', which implies destruction, but no details on irreversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, but could integrate the path more elegantly. Adequately short but not optimally structured.
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?
Minimal for a delete tool with nested parameters and no output schema; lacks response behavior, error cases, or confirmation. Incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description only lists the URL template without explaining task_id or time_entry_id meaning, sources, or constraints.
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 the verb 'Delete' and the resource 'time entry', with the HTTP DELETE method and URL path. Distinguishes itself among siblings like create and update time entry tools.
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 on when to use versus alternatives, no prerequisites or conditions mentioned. Agent must infer from tool name alone.
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 provided, and the description only says 'Get one task info' without disclosing behavior like response format, error conditions, or safety. The agent has to infer it's a read operation from the HTTP method.
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?
Very short and to the point, including the HTTP method and tag. Every sentence is useful, though more context could be added without becoming verbose.
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?
Given the number of sibling tools and the lack of output schema, the description is insufficient for an agent to correctly select and invoke this tool. Missing details about response and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a required 'id' parameter, but the description adds no details about its format, constraints, or purpose. With 0% schema description coverage, the description should compensate but fails to do so.
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 one task info' with the HTTP method and endpoint, which is specific and distinguishes it from 'get_tasks' that retrieves multiple tasks.
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 on when to use this tool vs alternatives like weeek_get_tasks or other task-specific tools. No mention of prerequisites or context.
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 provided. The description only states the HTTP method (GET), implying read-only, but fails to disclose any other behavioral traits such as authentication needs, rate limits, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but repeats 'Get portfolio' from the title. It includes HTTP method and tags, which are partially redundant. Could be more concise by removing duplication.
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?
Given the large set of sibling tools, especially 'weeek_get_portfolios', the description does not differentiate. No output schema means the description should hint at return format, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning to the 'id' parameter beyond what the schema provides (required, string or number). Does not explain what the ID represents.
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 states 'Get portfolio' and the HTTP method/URL, clearly indicating the resource and action. However, it does not differentiate from sibling 'weeek_get_portfolios' which likely returns all portfolios.
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?
No explicit guidance on when to use this tool versus alternatives. The name implies it retrieves a single portfolio by ID, but without context to contrast with listing or other retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only repeats the HTTP method and resource name, without indicating read-only nature, authentication needs, rate limits, or any side effects. This is insufficient for an agent to infer safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but contains redundancy ('GET /user/me' and 'Get profile' repeat the same idea). It could be more concise by combining, and the space could be used for additional context. It is adequately sized but not optimally structured.
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?
Given the lack of output schema and annotations, the description is incomplete. It does not specify the return value scope, whether the endpoint requires authentication, or any behavioral traits. For a simple read tool, more context (e.g., that it returns the current user's full profile) would 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 tool has no parameters, and the schema coverage is 100% (empty). The description does not add parameter information, but none is needed. A baseline of 4 is appropriate given zero parameters, though the description could have explicitly noted that no parameters are required.
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 profile' and the HTTP method/path '/user/me', indicating it retrieves the authenticated user's profile. However, it does not differentiate from sibling tools like weeek_get_workspace_info that may also return user-related data.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or scenarios where other tools would be more appropriate.
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 provided, and the description does not disclose any behavioral details such as whether the move is destructive, requires specific permissions, or what happens to previous positions. The description only restates the action.
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 concise with a single sentence and the HTTP method, fitting the minimal format. It is front-loaded with the action. However, it could be slightly more efficient by omitting the 'Tags: Project' part if not essential.
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?
Given no output schema and no annotations, the description should provide more context about the tool's effect, but it does not. The nested objects in the schema are not explained, leaving ambiguity about how to construct the request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the schema. With 0% schema coverage in the description, it should compensate by explaining the path and body parameters, but it does not. The schema itself has some descriptions for after/before, but the description ignores them.
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 'Move a custom field option' with the full HTTP path. However, it does not differentiate from sibling variants (_2, _3) which may have 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like weeek_move_a_custom_field_option_2 or other move tools. No conditions or prerequisites mentioned.
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 exist, so description must disclose behavior. It only mentions HTTP method and body type, omitting side effects, required permissions, destructive nature, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but at the expense of necessary detail. It is a single sentence but lacks substantive information about usage or parameters.
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?
Given the input schema has nested objects and multiple fields, and no output schema exists, the description is too sparse. It does not cover what fields can be updated or the expected response, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameter beyond 'Body: application/json', leaving 2 parameters (path with id, body with multiple fields) completely undocumented.
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 HTTP method (PUT) and resource (a contact), matching the title. It distinguishes from creation, deletion, and retrieval tools among siblings.
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 on when to use this tool versus alternatives like create or delete. No conditions, prerequisites, or exclusion criteria provided.
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 traits such as idempotency, side effects, authentication requirements, or rate limits. The HTTP method and endpoint are stated, but not enough for an agent to understand the tool's full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus tags/body type), which makes it concise but lacking structure. It front-loads the endpoint but omits crucial details, so it's not optimally useful despite its brevity.
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?
Given the lack of output schema and annotations, the description is insufficient. It does not explain return values, error conditions, or any required context, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (body with funnelId, path with id), but the description does not explain their meanings or usage. With 0% schema description coverage, the description fails to add value beyond the raw 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 (update), the resource (deal funnel), and provides the HTTP method and endpoint. It distinguishes the tool from siblings like weeek_update_a_deal or weeek_update_a_funnel by focusing specifically on the funnel of a deal.
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 like weeek_update_a_deal or weeek_update_a_funnel_status. The description lacks any context about prerequisites or scenarios.
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. It only specifies HTTP method and body type (multipart/form-data) but omits critical traits like file size limits, overwrite behavior, authentication requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It front-loads the HTTP method and endpoint, but the brevity comes at the cost of missing essential details. It is not concise in a helpful way.
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?
Given the complexity of a file upload with nested parameters and no output schema, the description is far from complete. It does not explain return values, file type constraints, or behavioral nuances, leaving the agent underinformed.
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 some descriptions for nested properties (e.g., file path, filename, fieldName), but top-level parameters (form, path, files) lack description. The description adds 'Body: multipart/form-data' which hints at form parameter usage but does not add significant meaning beyond the 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 verb 'Upload attachments' and the resource 'tasks' via the endpoint. It is specific to task attachments. However, it does not distinguish from the sibling tool 'weeek_upload_attachments_2' which likely has similar functionality, reducing clarity.
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 on when to use this tool versus alternatives (e.g., weeek_upload_attachments_2) or when not to use it. Lacks context for prerequisites or typical use cases.
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 HTTP method and that it creates a phone, but does not mention idempotency, error handling, response format, or whether existing phones are affected. This is adequate for a simple creation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three fragments) and front-loaded with method and endpoint. However, it sacrifices clarity for brevity, missing important details. It earns a 3 as it is minimally viable but could be improved without becoming verbose.
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?
Given minimal schema coverage, no output schema, and the presence of sibling phone creation tools, the description lacks key context. It does not explain that the phone belongs to an organization, nor does it describe the response. An agent with only this description would struggle to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only says 'Body: application/json' without describing the required 'phone' string or the 'organizationId' in the path. An agent would not know what values to provide or constraints like maxLength.
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 'Create a phone' and includes the HTTP method and URL path, which indicates it creates a phone for an organization. However, it does not explicitly mention that it adds a phone to a specific organization, and there is a sibling 'weeek_create_a_phone_2' that could create phones for other entities, leaving some ambiguity.
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 on when to use this tool versus alternatives. The description does not differentiate from sibling tools like 'weeek_create_a_phone_2' nor specify prerequisites such as needing an organization ID or that a phone number must be unique.
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 bears full responsibility for behavioral disclosure. It only states the action and endpoint, omitting details about side effects (e.g., reordering, persistence), required permissions, or idempotency. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes unnecessary technical details (HTTP method, tags) that are not helpful for an AI agent. It could be more natural and focused. Still, it is not overly verbose.
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?
Given the complexity (nested objects, sibling tools) and lack of output schema, the description is missing context such as what 'global' means versus regular custom field options, and how moving affects the UI. The agent may not understand when to use 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 provides descriptions for parameters like 'after' and 'before', including mutual exclusivity. The tool description adds no parameter-level information. With schema coverage at 0% (meaning the tool description doesn't cover parameters), the description does not compensate, but the schema itself is adequate, so score is baseline 3.
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 states 'Move global custom field option' which clearly indicates the action and resource. However, it does not differentiate from sibling tools like weeek_move_a_custom_field_option, which may cause confusion. The inclusion of technical details like endpoint and tags is extraneous.
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?
The description provides no guidance on when to use this tool versus alternatives such as weeek_move_a_custom_field_option or weeek_move_a_custom_field_option_2. An agent would have to infer the difference from the tool name alone.
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 should disclose behavioral traits. It only states it's a GET request (implicitly read-only) but omits pagination, sorting, filtering behavior, or any side effects. The return format is not described.
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?
Three short sentences, front-loaded with HTTP method. Minor redundancy: 'Get all organizations' appears in title and description. Could be trimmed without loss.
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?
Given no output schema and complex filtering parameters, the description is insufficient. It does not explain that results are paginated, sortable, filterable, or what the response structure looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions in schema fields?, but actually some exist; however metric shows 0%). The description adds no explanation for the query parameters or how to use them, failing to compensate for the lack of schema documentation.
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 all organizations via GET /crm/organizations. It distinguishes from siblings like weeek_get_a_organization by specifying 'all', and from other 'get_all' tools by naming 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like weeek_get_a_organization for a single record, or how it relates to similar list endpoints. No exclusions or prerequisites mentioned.
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?
The description reveals the HTTP method (GET) implying read-only, but no annotations are provided, so the description carries the full burden. It lacks details about pagination, filtering, permissions, or any side effects. Minimal behavioral context beyond the method.
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 extremely concise: three short sentences. It front-loads the endpoint and purpose, with no wasted words. However, it is borderline too terse and could include a bit more context without losing conciseness.
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 that this is a simple list endpoint with no parameters and no output schema, the description is minimally adequate. It tells the agent what it does and the HTTP method, but does not explain return format, behavior when filtering is needed, or how it relates to other list tools (e.g., 'weeek_get_all_contacts'). A bit more context would be beneficial.
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 has zero parameters with 100% coverage, so the schema already documents that no parameters are needed. The description adds no parameter information. Following guidelines, with high schema coverage, baseline is 3. The description does not even state that no parameters are required.
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 operation ('Get project list') and the resource ('/tm/projects'), using a specific verb and resource. It distinguishes from sibling tools like 'weeek_get_project' which retrieves a single project. However, it could be more explicit about the scope (e.g., 'list all projects in the workspace').
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 on when to use this tool vs alternatives. For example, it does not mention that to get a single project, one should use 'weeek_get_project'. No exclusions or context for selection.
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 is the sole source of behavioral information. It only mentions the HTTP method and partial body type. It does not disclose idempotency, side effects (e.g., task deletion if last location), permission requirements, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant boilerplate ('Tags: Task. Body: application/json.') that adds no value. It is minimally sufficient but wastes space on irrelevant details.
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?
Given no output schema and no annotations, the description is incomplete. It fails to explain return values, error handling, or the effect of the operation. With sibling tools performing similar tasks, more context is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning beyond the schema. It does not explain 'projectId' or 'task_id' purpose, format, or constraints. The description merely repeats the endpoint and body type without clarifying 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 action 'Remove a task from a project' and the HTTP method DELETE. It directly contrasts with sibling like 'weeek_add_a_task_to_a_project', making the tool's 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'weeek_detach_a_task') nor any prerequisites or exclusions. The description lacks context for decision-making.
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 only indicates 'GET /ws/tags' implying a read operation, but does not clarify if there are pagination, rate limits, or what exactly is returned (e.g., all tags in workspace vs. filtered). This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is repetitive ('Tags: Tags') and not well-structured. It could be a single clear sentence. It is concise but at the expense of clarity.
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?
Given that there is no output schema, the description should provide some indication of the return format or scope. It only says 'Tag list' without any elaboration on the data structure or context. This is insufficient for a complete understanding.
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% (empty schema). According to guidelines, baseline is 4 when no parameters exist. The description does not add parameter info, but none is needed.
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 states 'Tag list' and 'GET /ws/tags', making it clear that the tool retrieves a list of tags. However, it is somewhat tautological and does not distinguish from sibling tools like 'weeek_create_tag' or 'weeek_get_project_list', but the name itself is descriptive enough.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions under which this tool should be chosen over other list 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?
No annotations provided. Description does not disclose side effects (e.g., whether the global field is deleted from its original scope, how existing data is affected, or any irreversible changes). For a mutation, this is insufficient.
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 short and gets to the point, but includes unnecessary technical details ('POST /tm/custom-fields/{id}/transfer-to-project' and 'Tags: Custom fields') that clutter it. It could be more concise by focusing on the core action.
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?
Given no annotations, no output schema, and two parameters with nested objects, the description is incomplete. It does not explain the return value, prerequisites, or consequences of the transfer. The agent cannot fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters. It only mentions 'Body: application/json', but does not describe the 'path' or 'body' structure beyond what the schema provides. The schema itself is self-explanatory but the description adds no value.
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 'Transfer global custom field to project', specifying the verb, resource, and target. It distinguishes from sibling tools that transfer regular custom fields (e.g., weeek_transfer_custom_field_to_project) by including 'global'.
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 on when to use this tool versus alternatives like weeek_transfer_custom_field_to_project. Does not explain what a global custom field is or provide context for when a transfer is appropriate.
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 burden. It states 'Un Archive project' but does not disclose behavioral traits such as whether the operation is destructive, reversible, requires specific permissions, or what changes are made. The additional lines about HTTP method and body type add minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant restatement of the name ('Un Archive project'). It front-loads the HTTP method but lacks structure. Every sentence serves a purpose, but conciseness could be improved by removing duplication.
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?
Given the low schema coverage, no output schema, and no annotations, the description is incomplete. It fails to explain the effect of un-archiving a project, any prerequisites, or the response format. The agent is left with insufficient context to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'Body: text/plain' for the body parameter and leaves the 'id' field in the path completely unexplained. The description adds no semantic meaning beyond the schema types.
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: 'Un Archive project'. The verb 'un-archive' and resource 'project' are specific. It distinguishes from the sibling 'weeek_archive_project' by both name and opposite action, so purpose is well-defined.
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 on when to use this tool vs alternatives. There is no mention of prerequisites, conditions, or explicit when-not to use. The existence of 'weeek_archive_project' implies context, but the description itself provides no usage direction.
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?
The description implies a read-only GET operation but does not disclose behavioral details (e.g., whether it returns paginated results, ordering, or error handling). Without annotations, this is minimal but acceptable for a simple list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes the HTTP method, path, and a brief purpose. It could be improved with structured sections (e.g., usage notes).
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 operation, the description covers the basic purpose. However, it lacks details about the response format, pagination, or authentication, which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter description beyond the schema. The funnelId parameter is not explained (e.g., format, required, or how to obtain it). Schema coverage is 0%, so the description adds no value 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 the HTTP method, resource path, and action: 'Get all funnel statuses'. It explicitly requires a funnelId and is distinct from sibling tool 'weeek_get_a_funnel_status' which gets a single status.
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?
No explicit usage context or alternatives are provided. The description does not mention when to use this tool versus alternatives like the single-status version.
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 lacks behavioral disclosures such as authentication requirements, rate limits, or read-only nature. It only states the endpoint and tags, which is insufficient for an agent to understand side effects or constraints.
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 very concise with two short sentences. It is not verbose, but the information is minimal. It could be structured better to include more context without adding length.
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 has no parameters and no output schema, so the description should clarify what the response contains (e.g., list of members) or any limitations. It does not provide this, making it incomplete for an agent to understand the full 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 has zero parameters, so the description doesn't need to add param info. Schema coverage is 100% by default, and the description aligns with this. A baseline score of 4 is appropriate for a parameterless tool.
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 HTTP endpoint 'GET /ws/members' and that it retrieves workspace members for the current workspace. This specific verb+resource combination distinguishes it from other retrieval tools like weeek_get_workspace_info.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or contrast with sibling tools like weeek_get_workspace_info or weeek_get_project_list.
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 carry the full burden of behavioral disclosure. It only mentions 'GET /ws' and 'for current token', indicating it's a read operation, but lacks details on authentication, rate limits, or any potential side effects. With zero annotations, this is insufficient.
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 with no fluff. It front-loads the HTTP method and purpose, making it quick to parse. 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?
Despite having no parameters and no output schema, the description fails to elaborate on what 'workspace info' includes (e.g., name, ID, members, settings). The tool is simple but the description is too minimal to fully guide the agent on the return value.
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 has zero parameters, so schema coverage is 100%. The description adds no meaning beyond the tool name, saying essentially the same thing. For a no-parameter tool, a baseline of 4 is appropriate only if the description adds value; here it does not, thus a 3.
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: 'Get workspace info for current token'. The verb 'Get' and resource 'workspace info' are specific, and it distinguishes from siblings which are mostly CRUD operations on other entities (contacts, deals, tasks, etc.).
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 when workspace info is needed but provides no explicit guidance on when to use this tool versus alternatives. No exclusion criteria or comparisons with sibling tools are given, leaving the agent to infer context.
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 must fully disclose behavioral traits. The description only repeats the HTTP method and 'Get all currencies', omitting details like authentication, rate limits, or pagination. This is insufficient for an unannotated 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 extremely concise at one sentence, but it includes redundant tags (HTTP method, 'Tags: Currencies') that could be omitted. Still, it is not verbose and front-loads the key action.
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?
Given no output schema, the description should explain what is returned (e.g., list of currency codes, names). It does not, leaving the agent without essential context for a simple list endpoint.
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% (no parameters), so baseline is 4. The description does not need to add parameter info, and it does not.
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 all currencies', which is a specific verb and resource. It distinguishes from sibling tools as no other tool mentions currencies, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While there are no competing currency tools, the description does not provide any context or exclusions, leaving usage implied.
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 provided, and the description only restates the HTTP method and resource name. It does not disclose any behavioral traits such as pagination, rate limits, or response format, leaving the agent without additional guidance.
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 extremely concise, communicating the key purpose and API endpoint in just three short sentences. However, the inclusion of 'Tags: Funnels' may be extraneous for an agent.
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?
Despite the tool's simplicity, the description fails to mention what the response includes (e.g., an array of funnel objects or their key fields). Without an output schema, this omission leaves the agent without complete contextual understanding of the output.
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 no parameters, and the schema coverage is complete. The description does not need to add parameter semantics, so score 4 as per 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 clearly states the action (GET) and resource (all funnels), and distinguishes from the sibling 'weeek_get_a_funnel' which retrieves a single funnel.
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 no explicit guidance on when to use this tool versus alternatives, but the name and sibling 'weeek_get_a_funnel' imply its use for retrieving all funnels.
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:

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

Score Badge

Copy to your README.md:

[![weeek-mcp MCP server](https://glama.ai/mcp/servers/MaxViksna/weeek-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MaxViksna/weeek-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/MaxViksna/weeek-mcp'

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