boostu-teamleader-mcp

Server Quality Checklist

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

Latest release: v2.1.4
Disambiguation2/5
Many tools have overlapping purposes, such as teamleader_meetings_list and teamleader_list_events both listing calendar events, and teamleader_create_event vs. teamleader_meetings_create. The naming inconsistency (e.g., resource_action vs. action_resource) further confuses which tool to use, especially with 103 tools to choose from.
Naming Consistency2/5
Tool names mix two conventions: teamleader_<resource>_<action> (e.g., teamleader_invoices_list) and teamleader_<action>_<resource> (e.g., teamleader_list_contacts). Even within the same resource, actions are inconsistently ordered (e.g., teamleader_create_invoice vs. teamleader_invoices_book). This inconsistency makes it harder to predict tool names.
Tool Count1/5
With 103 tools, this server far exceeds any reasonable scope for an MCP server. The sheer volume overwhelms agents and makes tool selection error-prone, even if each tool is individually useful. The count should be reduced or grouped into multiple specialized servers.
Completeness3/5
The server covers many Teamleader resources (contacts, companies, deals, invoices, quotations, tickets, projects, etc.) and provides core list/get/create operations. However, obvious gaps exist: there is no update or delete for contacts, companies, deals, or tasks, and no update/delete for calendar events. This leaves agents unable to perform complete lifecycles for major entities.
Average 3.3/5 across 100 of 103 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on July 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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, so the description carries the full burden of behavioral disclosure. It only says 'List payment terms', but does not mention pagination behavior, response format, whether it returns inactive or archived terms, or any other operational details.
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 it is under-specified rather than concisely comprehensive. It lacks any detail beyond the bare action, making it more of a label than a helpful description.
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 provides no contextual information about how results are returned, how pagination works, or any other nuances. The description is completely inadequate for an agent to use the tool effectively.
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 covers 50% of parameters (page_size has description 'max 100'), but the tool description adds no information about 'page' or 'page_size'. The parameters are generic pagination fields, but the description does not even hint that pagination is supported.
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 'List payment terms' simply restates the tool name 'teamleader_payment_terms_list' without adding any additional scope or context. It is a tautology, providing the same information as the name 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?
There is no guidance on when to use this tool versus alternatives. No mention of use cases, prerequisites, or comparisons to other list tools like teamleader_tax_rates_list or teamleader_custom_field_definitions_list.
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 behavioral disclosure. However, 'List tax rates' only states the basic operation and does not reveal pagination behavior, response format, or any side effects. The agent gains no additional insight 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 a single, short sentence, which is concise and front-loaded. However, it is under-specified rather than efficiently informative, so it does not fully earn its place as a complete tool description.
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 and no annotations, the description should explain return values and behavior. It does not mention what the list returns, whether pagination is implicit, or any other context. The tool is a simple list, but even basic details are missing, making the description inadequate for an agent to invoke it 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?
The schema has two parameters with 50% description coverage (page has no description, page_size has 'max 100'). The tool description adds no parameter information, so it does not compensate for the gap. The parameter names are somewhat self-explanatory, but the description fails to clarify their usage or formatting.
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 'List tax rates' clearly states the action and resource, but it essentially restates the tool name (teamleader_tax_rates_list) without providing differentiation from the sibling tool teamleader_withholding_tax_rates_list. It is more informative than a pure tautology but lacks scope or distinguishing details.
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, such as teamleader_withholding_tax_rates_list. There is no mention of context, prerequisites, or exclusions, leaving the agent without any usage direction.
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 must carry the full behavioral disclosure. It only states the action without any mention of side effects, permissions, idempotency, or potential errors. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise, but it is under-specified. It conveys only the basic action and omits necessary detail, which is a case of under-specification rather than effective 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 no annotations and no output schema, the description is extremely thin. It doesn't explain the required parameters, relationship to other project tools, or any behavioral constraints. The description is inadequate for an agent to use the tool correctly in most real scenarios.
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 parameter explanations. The bare parameter names 'id' and 'quotation_id' are ambiguous (e.g., 'id' could refer to a project or something else). The description fails to clarify what each parameter 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 clearly states the action: linking a quotation to a project. The verb 'koppel' is specific and distinguishes this from sibling operations like teamleader_projects_remove_quotation. However, the term 'nextgen-project' is domain-specific jargon that could confuse agents unfamiliar with the system.
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 is provided. The description gives no context about when to use this tool, whether certain project or quotation states are required, or how it relates to sibling tools like remove_quotation. The agent is left to infer basic usage from the name.
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, but it only states the obvious action. It reveals nothing about pagination, response format, rate limits, or other runtime behavior, offering 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 exceptionally concise, consisting of a single short sentence with no redundancy. However, its brevity sacrifices substance and structure, containing only a subject and verb without contextual layers.
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 two-parameter list tool, the description is extremely thin. It lacks any mention of pagination behavior, the nature of 'units of measure', or how the output is structured, making it barely sufficient for selecting and invoking 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?
The description does not explain the 'page' or 'page_size' parameters. The schema provides a description only for page_size ('max 100'), leaving 50% of parameters undocumented, and the description does not compensate for this gap.
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 'List units of measure' simply restates the tool name in natural language without adding any scope or distinguishing details. It is a tautology that provides no additional information beyond the resource being listed.
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. The description offers no context, exclusions, or references to sibling tools, leaving the agent to infer usage solely from the tool name.
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 says 'List product categories' with no disclosure of pagination behavior, read-only nature, or any side effects, leaving the agent without essential safety/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 a single concise sentence with no fluff, but it is under-specified. It does not include any additional context that would make it appropriately sized for a tool with pagination 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 optional pagination parameters and lack of annotations/output schema, the description is incomplete. It omits return value details, pagination behavior, and any caveats, making it insufficient for reliable 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 schema describes page_size with a max of 100, but the tool description adds nothing about pagination or how parameters affect results. The 'page' parameter lacks a schema description, and the tool description does not compensate, providing minimal 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 uses a clear verb ('List') and resource ('product categories'), making the action explicit. However, it does not distinguish from sibling tools like teamleader_products_list, and it essentially restates the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 teamleader_products_list. There is no mention of typical scenarios, 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?
No annotations are provided, and the description does not disclose behavioral traits such as whether the id must exist, error handling, or whether it returns full subscription details. The description simply restates the function without adding context about performance, permissions, or edge cases.
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, which is efficient. However, it is so brief that it sacrifices useful context, though it does not waste words.
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 1 parameter, no output schema, no annotations, and 0% schema description coverage, the description is too minimal. It does not explain what information is returned or how the id is obtained, making it 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.
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 'id' parameter beyond implying it identifies a subscription. The schema only states it is a required string, but no format, source, or meaning is provided, leaving the agent to guess.
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 retrieves a single subscription by id, which is a specific verb+resource. However, it does not distinguish itself from sibling tools like teamleader_subscriptions_list, teamleader_subscriptions_create, teamleader_subscriptions_update, and teamleader_subscriptions_deactivate beyond the implied 'info' 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. While the name and description imply retrieval of a single subscription, there is no explicit mention of when to prefer this over teamleader_subscriptions_list or other subscription tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'List teams,' implying a read-only operation, but does not explain return format, pagination behavior, permissions, or any side effects. This is insufficient for an agent to understand 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with no wasted words, but it borders on under-specification. It is front-loaded with the main purpose but lacks any supporting details, making it less effective than a well-structured description with necessary 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?
For a simple list tool with two pagination parameters and no annotations or output schema, this description is too thin. It does not mention that results are paginated, what page/page_size control, or the response format, leaving the agent to infer critical usage details.
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 description coverage is 50% (page_size has a max-100 note, page has none). The description adds no meaning about either parameter, so an agent must rely solely on the parameter names. Given the partial schema coverage, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (list) and resource (teams), but it essentially restates the tool name 'teamleader_teams_list' without adding detail about scope, filtering, or output format. It is clear but minimal, and while it distinguishes from siblings by naming a different entity, it does not go beyond that.
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 about when to use this tool versus other list tools such as teamleader_tickets_list or teamleader_projects_list. There is no mention of alternatives, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'List custom field definitions' and gives no information about pagination behavior, return structure, or potential side effects. This is essentially just restating the tool name without adding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. Structure is clean and front-loaded. However, it is under-specified in terms of content, which prevents a perfect score—though conciseness itself is not the issue.
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, no annotations, and a minimal description. For a list operation, the description does not mention what fields are returned, whether pagination is required, or how to use it in conjunction with the info tool. This is insufficient for an agent to understand the full context of the 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?
Schema coverage is 50%, with only 'page_size' having a description ('max 100'). The tool description adds no parameter semantics whatsoever. The agent must rely on the schema alone, which documents the parameters but not their intended usage or defaults. The description should have explained pagination semantics 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 'List custom field definitions' clearly states the verb (list) and resource (custom field definitions). However, it does not differentiate from the sibling tool 'teamleader_custom_field_definitions_info', which presumably fetches a single definition. The plural 'definitions' hints at list-all behavior, but explicit distinction is absent.
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 pagination usage, when to call this instead of the info tool, or any prerequisites. The description provides no 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?
With no annotations, the description must carry the burden of behavioral disclosure. It only says 'List price lists' and does not mention read-only behavior, pagination behavior, or what is returned. The name implies a read operation, but the description adds no explicit behavioral information.
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 a single short sentence, which is concise, but it is under-specified to the point of conveying no more information than the tool name. It lacks essential details, making it closer to under-specification than effective 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?
This is a list tool with two parameters and no output schema, yet the description does not explain return values, pagination, or any filtering context. It is minimally adequate at best, but incomplete for an agent to understand what the tool does beyond the name.
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 to the parameters. The schema documents page_size with 'max 100', but page is undocumented, and the description does not explain either parameter or how pagination works. With only 50% schema coverage, 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 'List price lists' clearly states the action (list) and the resource (price lists). It differentiates from sibling tools by naming the specific resource, though it provides no additional context to distinguish it from other list 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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it note any prerequisites or contexts where it is applicable.
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 of behavioral disclosure. It only says 'Dupliceer een nextgen-project' and does not indicate whether this is a mutation, what side effects occur (e.g., copies all data, creates a new ID), or any permission requirements. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and efficiently worded, though minimal in content. It avoids verbosity and clearly states 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?
With one parameter and no output schema, the description is incomplete. It does not explain the behavior of the duplication process, such as whether a new project ID is returned, or how the duplicated project relates to the original. This lack of context makes it difficult for an agent to anticipate the tool's effect.
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 includes one parameter 'id' with 0% description coverage. The description does not explain what 'id' refers to or how it should be provided. While the parameter name is self-explanatory, the 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 uses a clear verb 'Dupliceer' (duplicate) targeting a 'nextgen-project', which distinguishes it from sibling project operations like create, update, or delete. However, the term 'nextgen' is not explained, so the clarity is slightly reduced.
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 state prerequisites, exclusions, or preferred contexts. The only clue is the verb 'dupliceer', which merely restates the tool's purpose.
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 of behavioral disclosure. It only says 'List', which implies a read-only operation, but doesn't disclose pagination behavior, response format, or any edge cases. This is a minimal level of 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 a single short sentence, which is concise, but it omits important details and has no structure for broader context. It's appropriately sized for a simple tool but borderline under-specified, earning a middle score.
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?
Without an output schema, the description should clarify what a successful call returns (e.g., array of pipeline objects). It doesn't, and pagination parameters are not explained. For a simple list tool, this is incomplete but not severely flawed.
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 describes page_size (max 100) but not page. The description adds no parameter information, leaving page's purpose and constraints undefined. With 50% schema coverage and zero description compensation, parameter semantics are weak.
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 a specific verb ('List') and resource ('deal pipelines'), clearly distinguishing it from sibling tools like deal_phases_list or deal_sources_list. However, it lacks any scope qualifiers (e.g., filtering or ordering) that would fully differentiate it from other list 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?
The description provides no guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. It simply states the action without context, leaving the agent to infer when 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 disclose behavior, but it only states the action. It does not mention pagination, read-only nature, rate limits, or response format, leaving the agent without critical 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 concise (one sentence), but it is under-specified rather than efficiently packed with value. It reads as a tautology of the tool name, offering no additional insight, so it fails to earn high marks for structure.
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 minimal schema (no output schema, only two params) and no annotations, the description should explain what a 'deal source' is, how pagination works, and what the response contains. It does none of this, leaving the agent under-informed.
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 does not explain any parameters. While the schema provides a 'max 100' hint for page_size, 'page' remains undefined, and the description adds no meaning about pagination semantics 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 'List deal sources' uses a clear verb and resource, making its purpose understandable. It doesn't distinguish itself from sibling list tools by mentioning scope or filtering, but the resource name 'deal sources' is unique enough that the intent 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 alternatives, or what scenarios it fits. There is no mention of permissions, prerequisites, or exclusions, so the agent receives no 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 the full burden of behavioral disclosure. It only implies a read-only list operation but does not mention pagination, response format, or any other behavioral traits. The schema hints at pagination via page/page_size, but the description adds nothing about 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 extremely concise ('List departments'), which is efficient, but it is under-specified rather than properly concise. It lacks important context, so while it earns points for brevity, it misses the mark on staying appropriately 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 is a list operation with pagination parameters, the description is incomplete. It does not mention pagination behavior, response structure, or any notes about what 'departments' includes. Since there is no output schema, the description should provide more context for the 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 description coverage is 50% (page_size has a description 'max 100', page does not). The description does not mention or explain either parameter. Since page lacks a schema description and the description does not compensate, the agent gets minimal guidance on 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 'List departments' uses a specific verb and resource, clearly indicating the action and target. It distinguishes from sibling tools by the unique resource 'departments', though it lacks any extra context like scope or filtering.
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 simply states 'List departments' without any context, exclusions, or references to 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention that this is a read-only operation, nor does it describe pagination behavior, return format, or any side effects. 'List meetings' implies a non-destructive action but fails to state it explicitly.
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 a single, concise sentence with no wasted words. However, it is overly terse, underspecifying the tool's behavior and parameters. It is structured appropriately 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 the tool's low complexity (simple list with two pagination parameters) and no output schema, the description still falls short. It does not clarify that results are paginated or how the page parameters affect the response. The lack of annotations and minimal description leaves critical usage details unstated.
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 50% coverage (only page_size has a description), and the tool description does not mention page or page_size at all. Thus, the description adds no meaning beyond the schema, and the 'page' parameter remains 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 uses the specific verb 'List' with the resource 'meetings,' clearly stating the tool's action. It distinguishes from sibling meeting tools (create, complete) by presenting a fundamentally different operation, though it does not explicitly differentiate in text.
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, no prerequisites, and no mention of alternatives. It simply says 'List meetings,' leaving the agent to infer the usage context from the tool name and sibling names.
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 states the basic action and does not mention pagination, return format, or any other behavioral details, which is a significant gap for a list 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?
At only two words, the description is extremely concise and front-loaded, with no redundant content. While minimal, it does not waste tokens and is easy to parse.
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 annotations, the description should provide more context about response structure or pagination behavior. It is barely sufficient for a simple list tool but lacks enough detail for an agent to know what to expect.
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 provides a description for page_size (max 100) but not for page. The description adds no parameter semantics, so the agent must rely on the parameter names alone to infer their purpose.
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 identifies the action ('List') and the resource ('deal phases'), which distinguishes it from sibling tools like teamleader_deal_pipelines_list or teamleader_deal_sources_list. However, it lacks any additional scope or context that would further differentiate it from other list 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. There is no mention of use cases, prerequisites, or relationships to other deal-related tools, leaving the agent to infer its applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'List lost reasons for deals' with no mention of pagination, sorting, return format, authentication requirements, or any other behavioral traits. This is minimally informative and does not go beyond the literal 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 a single, concise sentence with no redundant words. It is appropriately front-loaded with the main action and resource. However, the extreme brevity may sacrifice necessary detail, so it is not perfect.
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 explanations, the description is incomplete. A simple list tool may not need extensive context, but pagination behavior and result details are entirely missing. The description is usable but leaves significant gaps for an agent to understand the full 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?
The input schema defines two parameters, page and page_size, with only page_size having a description ('max 100'). The tool description provides no additional meaning for these parameters, leaving half of the schema parameters undocumented semantically. The description does not compensate for the gap.
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 a specific verb ('List') and identifies the resource ('lost reasons for deals'), making the tool's primary function clear. However, it does not differentiate this from other list tools among the many siblings, so it is clear but not fully distinguishing.
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. The description simply states what it lists, with no context about typical use cases or relationships to other deal-related tools like 'teamleader_list_deals' or 'teamleader_deal_phases_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?
There are no annotations, so the description carries the full burden. It only states the action without disclosing side effects, reversibility, permission requirements, or whether the deal is deleted or merely unlinked. Given the mutation nature, this lack of context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is easy to read and front-loaded. It avoids redundancy, but the extreme brevity leaves out critical details; however, for a simple action, it is appropriately concise.
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 only two parameters, the description is incomplete because it does not explain which parameter is which or provide any context about nextgen projects. The output schema is absent, but parameter clarity and behavioral context are still missing, making the tool under-specified.
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 two required parameters (id and deal_id) with 0% description coverage. The description does not explain what 'id' refers to (likely the project ID) or clarify the relationship between the two parameters. The agent is left to guess parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'ontkoppel' (unlink) with the resource 'deal van een nextgen-project', clearly stating the action and target. It distinguishes from sibling tools like remove_quotation and add_deal, as it specifically refers to removing a deal from a 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 such as teamleader_projects_remove_quotation or teamleader_projects_add_deal. The description does not mention any prerequisites, exclusions, or situations where this tool is applicable.
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. It only says 'reopen' without explaining side effects, prerequisites, or whether the operation can be reversed. This is insufficient disclosure for a state-changing 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 a single brief sentence that communicates the core action without redundancy. It is appropriately sized for the tool's simplicity, though it sacrifices detail for 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 annotations and output schema, the description must fully document the tool's behavior and parameters. It fails to explain the 'id' parameter or any operational details, making it incomplete for an agent to invoke the tool confidently.
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 one required 'id' parameter, but the description does not mention it or clarify what the id refers to (presumably a project id). With 0% schema description coverage, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'reopen' and resource 'nextgen project'. It distinguishes itself from sibling tools like 'teamleader_projects_close' and 'teamleader_projects_update'.
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 about when to use this tool or alternatives. The description only states the action, leaving the agent to infer that it applies to closed projects. No exclusions or alternative tool references 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?
With no annotations, the description carries the full burden of behavioral disclosure. The 'SIDE EFFECT' note merely restates the obvious creation of a record and adds no meaningful information about permissions, reversibility, or side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (two short sentences) and front-loads the core purpose. However, the second sentence about 'SIDE EFFECT' is largely redundant with the first and could be omitted without loss of meaning.
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 create operation with 5 parameters, no output schema, and no annotations, the description is inadequate. It does not explain return values, required inputs (beyond schema), or any behavioral nuances, leaving the agent without sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions (100% coverage) for all 5 parameters, so the baseline is 3. The description adds no parameter-level meaning beyond the schema, nor does it compensate for any missing 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 the action ('Create a call activity') and resource ('call'), distinguishing it from sibling tools like calls_list and calls_complete. However, the redundant 'SIDE EFFECT: creates a call record' slightly muddies the purpose by implying an additional behavior beyond the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., calls_complete) or any prerequisites. The description only states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and target, but does not disclose any additional behaviors such as error handling, permissions, or return format. For a getter, this is minimal but not entirely misleading.
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 a single, efficient sentence that front-loads the core purpose. It is appropriately sized for a simple getter, but lacks supportive detail that could have been included without bloat.
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 quite thin. It does not explain what the response looks like, when to choose this over the list tool, or any usage context, leaving gaps for such a simple tool.
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 only says 'by id', which adds little over the schema's 'id' property. It does not explain the format, meaning, or any constraints of the id, leaving the agent with minimal semantic guidance.
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'), the resource ('custom field definition'), and the scope ('single by id'). This unambiguously differentiates it from the sibling 'teamleader_custom_field_definitions_list' tool, which would list multiple definitions.
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 the list tool or any other contextual cues, 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?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only states the action without explaining whether it modifies the project or deal, if it is idempotent, what happens if the deal is already linked, or what response is returned. This is insufficient for a mutation 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 a single short sentence with no redundant information or filler. It is appropriately terse, though it could be enriched with a bit more detail without losing efficiency.
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 linking operation with 2 plain string parameters and no output schema, the description gives only the bare action. It omits return value, side effects, and any conditions. Given no annotations, this is not complete enough for an agent to understand the tool's full 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?
The schema has zero description coverage, and the description adds no parameter clarification. It implies deal_id refers to a deal and id likely to a project, but does not explicitly state this mapping or any constraints. The field names provide some self-documentation, but the description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Koppel' = link) and clearly identifies the action: linking a deal to a nextgen-project. This distinguishes it from sibling tools like remove_deal or add_quotation. The only minor ambiguity is which parameter is the project, but the schema's field names partially resolve this.
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 context is provided. The description does not mention when to use this tool versus alternatives (e.g., remove_deal, add_quotation), nor any prerequisites like an existing project or deal. It gives zero guidance on selection or sequencing.
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 states 'Update an existing contact' without explaining whether the update is partial or full replacement, how tags are handled (merge vs overwrite), required permissions, or whether changes are irreversible. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words or repetition of schema details. It is appropriately short for a tool whose schema fully documents its parameters, though more behavioral context would be welcome.
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 moderate complexity (9 params, 1 required), no annotations, and no output schema. The description only covers the basic action and leaves out crucial details about behavior, return values, and usage context. It is not complete enough for an agent to confidently invoke the tool without additional assumptions.
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 100% coverage with descriptions for all 9 parameters, and the schema itself lists valid values for enums. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing contact in Teamleader Focus' clearly identifies the action (update) and resource (contact). It distinguishes itself from sibling tools like teamleader_create_contact (create vs update) and teamleader_get_contact (read vs write), but it does not differentiate from tag-specific updates like teamleader_contacts_add_tags, which also modify 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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of whether this should be used for general field updates while add_tags/remove_tags are reserved for tag management, nor any indication of prerequisites or edge cases where another tool 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.
Behavior1/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, but it only states 'Update an existing deal'. It does not disclose whether the update is partial or full-replace, whether missing fields are overwritten, permissions required, or what the response contains. This is a minimal statement with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, using only six words. However, it is so short that it omits useful details, making it somewhat under-specified. It earns its place 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 the tool's complexity (7 parameters, no annotations, no output schema), the description is far from complete. It does not explain update semantics (partial vs full), return behavior, or how it fits into a workflow like listing deals first. The schema helps, but the description leaves critical usage context unstated.
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 100% parameter description coverage, so the schema already documents all seven parameters. The description adds no parameter information, but per the rubric, high schema coverage yields a baseline of 3. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('existing deal'), clearly distinguishing it from sibling tools like teamleader_create_deal and teamleader_get_deal. It leaves no ambiguity about what action is performed.
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 does not mention prerequisites like fetching the deal with get_deal first, nor does it contrast with create_deal or clarify that only provided fields are updated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states 'List withholding tax rates' without indicating pagination, result format, read-only nature, or any side effects. While listing implies a read operation, the description does not explicitly confirm safety or explain behavior beyond the action itself.
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 with no wasted words, and the key action and resource are front-loaded. However, it might be too terse, lacking structural elements like additional clauses that could clarify scope or behavior, but it is appropriately sized for the minimal content it presents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with two optional params, but the description omits critical context: no mention of pagination, no output schema, no annotations, and no differentiation from the similar sibling 'teamleader_tax_rates_list'. For an agent to decide correctly, more contextual detail is needed, especially about the distinction between withholding and regular tax rates.
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 50% (only page_size has a 'max 100' description, page has none). The description adds no parameter semantics, leaving 'page' completely undocumented and not clarifying the meaning of 'page_size' beyond the schema. It fails to compensate for the incomplete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List withholding tax rates.' clearly states the action (list) and the specific resource (withholding tax rates), distinguishing it from the sibling tool 'teamleader_tax_rates_list' which covers regular tax rates. The verb+resource pairing 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 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 the difference between withholding tax rates and regular tax rates, nor any context about when this list is relevant. No exclusions or alternative recommendations are 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a mutation ('Add') but does not specify side effects such as whether tags are appended to existing tags or replace them, whether duplicate tags are allowed, or any permission requirements. This is insufficient for a write operation without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tagging operation.
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 should compensate with richer context. It does not mention behavior around existing tags, error conditions, or how the company is identified. While the operation is simple, the lack of additional context makes it incomplete for an agent to confidently invoke without guessing.
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 the parameters. It does not clarify that 'id' refers to a company ID or what format 'tags' should take (e.g., must tags already exist, what string format). The description only says 'one or more tags,' which loosely maps to the minItems constraint but adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('tags to a company'), making it clear what operation is performed. It differentiates from sibling tools like teamleader_companies_remove_tags and teamleader_contacts_add_tags by specifying the target (company vs contact) and action (add vs remove).
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 the use case—when you want to add tags to a company—but provides no explicit guidance on when to choose this tool over alternatives (e.g., teamleader_contacts_add_tags for contacts, or teamleader_companies_remove_tags to remove tags). It doesn't mention exclusions or prerequisites.
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 states the basic action and does not mention side effects, idempotency, required permissions, error behavior (e.g., if a tag doesn't exist), or whether changes are irreversible. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is appropriately sized for the straightforward action it describes.
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 schema, no annotations, and no output schema, the description still lacks essential details such as parameter meanings, usage context, and behavioral effects. It is just barely enough for an agent to guess the action but not enough to invoke it confidently without additional schema info.
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 does not explain that 'id' is the company identifier, nor whether 'tags' are tag names, IDs, or objects. The phrase 'one or more tags' echoes the schema's minItems but adds no meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'remove' with a clear resource 'tags from a company', distinguishing it from siblings like teamleader_contacts_remove_tags and teamleader_companies_add_tags. It precisely names the entity type (company) and the action, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 does not mention that for contacts one should use teamleader_contacts_remove_tags, nor contrast with adding tags. The description simply states the action without 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 provided, the description must communicate behavioral traits itself. It only states the basic operation without disclosing effects like whether existing tags are preserved, idempotency, or permission requirements. This is a bare statement of intent, not a behavioral disclosure.
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, focused sentence with no wasted words. It front-loads the action and object clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations, no output schema, and minimal description, the agent lacks context about return values, error conditions, or side effects. The id parameter is not explicitly defined. Given these gaps, the description is insufficient for full autonomous use.
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 does not explain the 'id' parameter beyond the implicit contact reference. It does clarify that 'tags' can have one or more items, matching the schema's minItems: 1 constraint, but leaves the identifier semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('tags to a contact'), using a specific verb and object. It distinguishes from sibling tools like teamleader_contacts_remove_tags and teamleader_companies_add_tags by specifying 'contact' and 'add'.
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 when to use teamleader_companies_add_tags or teamleader_contacts_remove_tags. No prerequisites or context are 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create', which implies a write operation, but does not mention side effects, required collaborators, permission needs, or any constraints. This is a minimal statement with no added 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the action and resource. There is no waste, though it is short and could arguably include more context without harm.
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 create operation with 11 parameters and no output schema, the description is overly minimal. It does not explain what the tool returns, any inter-field relationships, or how to select required IDs. The schema helps, but the overall context is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters have descriptions in the schema. The tool description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and names the resource 'deal/opportunity', which clearly distinguishes it from sibling tools like teamleader_get_deal, teamleader_update_deal, and teamleader_list_deals. It is unambiguous and action-oriented.
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, no prerequisites, and no exclusions. It merely states the function without context, so the agent receives no 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 provided, the description carries the full burden of behavioral disclosure. It simply says 'get detailed information' without mentioning that this is a read-only operation, what data is included in the response, or how errors like non-existent IDs are handled. The verb 'get' implies read-only, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Get') and the resource ('detailed information about a specific invoice'). It contains zero wasted words and is easily parseable, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), so the description is minimally adequate. However, without an output schema, the description should clarify what 'detailed information' entails (e.g., invoice lines, totals, status) to set expectations. The current description leaves that ambiguous.
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 100% coverage, with the 'id' parameter described as 'The invoice ID'. The description adds minimal semantic value beyond the schema, only implying that the ID references a specific invoice. Baseline of 3 is appropriate since the schema fully documents the 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 clearly states the tool retrieves detailed information for a specific invoice, using a specific verb ('Get') and resource. It is distinct enough from list/download siblings based on the verb 'get' and 'detailed information', but it does not explicitly differentiate itself from these alternatives, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 instead of similar tools like teamleader_invoices_download or teamleader_list_invoices. There is no mention of prerequisites, such as needing to first list invoices to obtain an ID, or any context for when 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 carries full responsibility for behavioral disclosure. While it mentions a side effect, 'creates a meeting record' essentially restates 'schedule a meeting' and does not reveal important behavior like whether invites are sent, availability is checked, or permissions are required.
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 a single, front-loaded sentence that is easy to parse. It is appropriately concise, though the brevity sacrifices depth. Still, it earns a high score for not wasting words.
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 annotations, the description should explain what the tool returns and any important behavioral context. It does neither, making it incomplete for an agent selecting among many create-oriented tools. It fails to mention return values, error conditions, or edge 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 input schema already provides descriptions for all 5 parameters, so the baseline is 3. The tool description adds no parameter-specific details beyond what the schema already states, such as how attendee_user_ids should be formatted or timezone handling.
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 ('Schedule a meeting') and resource (meeting). It also reinforces the create operation with 'SIDE EFFECT: creates a meeting record.' This distinguishes it from sibling tools like teamleader_meetings_list and teamleader_meetings_complete.
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 teamleader_create_event, teamleader_meetings_list, or other meeting-related tools. It lacks context about prerequisites, typical 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 are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., whether the existing owner is replaced), required permissions, or error behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the core purpose without unnecessary words. It is front-loaded with the action and reads clearly.
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 documentation, the description is too sparse. It does not cover return values, parameter semantics, or usage context, making it incomplete for an agent to confidently invoke the tool.
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 explicitly explain the parameters. While 'id' can be inferred as the project ID and 'user_id' as the user to add, this is not stated directly, and the description adds minimal value beyond the schema's property names.
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: adding an owner (user) to a nextgen project. It uses a specific verb ('toevoegen') and resource ('project'), and the term 'eigenaar' distinguishes it from sibling tools like remove_owner or add_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as teamleader_projects_assign or teamleader_projects_add_customer. There is no mention of prerequisites, exclusions, 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 are provided, so the description carries full responsibility for behavioral disclosure. However, it only describes the basic action without mentioning side effects, permissions, whether existing assignments are replaced, or any irreversibility. The description adds almost no transparency beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is front-loaded with the verb and object, making it easy to scan. While more detail could be added, the conciseness is ideal for a tool description.
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 simplicity, the description still lacks crucial context. The parameter 'id' is not explained, leaving users to guess whether it refers to the project or something else. With no output schema and no annotations, this description is insufficient for correct tool 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 description coverage is 0%, leaving the description to clarify parameters. It does hint that assignee_type can be 'user' or 'team', but it fails to explain the meaning of 'id' (likely project ID) and 'assignee_id'. The parameter names are generic and ambiguous without further explanation.
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: 'Wijs een gebruiker of team toe aan een nextgen-project' (Assign a user or team to a nextgen project). It specifies both the resource (user/team) and the target (nextgen-project), distinguishing it from sibling tools like unassign or add_owner.
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 simply states the operation without any context about prerequisites, exclusions, or preferred scenarios. No explicit or even implied usage conditions are 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?
No annotations are provided, so the description carries full responsibility. It discloses the removal action but does not mention whether it is reversible, what happens to the customer record, or any permission requirements. For a mutation tool, this lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no unnecessary words. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal given the tool has three required parameters, no output schema, and no annotations. It fails to explain key aspects like the project identifier and the exact effect of unlinking, making it 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.
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 clarify parameters. It only explains that the customer can be a contact or company (matching customer_type enum) but does not specify what 'id' refers to or how 'customer_id' is used, leaving the parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Ontkoppel' (unlink) and clearly identifies the resource: a customer (contact or company) from a nextgen project. This distinguishes it from sibling tools like add_customer or remove_owner.
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 about when to use this tool versus alternatives, nor are any prerequisites or exclusion criteria mentioned. The description only 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 provided, so the description must carry the burden of behavioral disclosure. It simply states the action without explaining side effects, reversibility, permission requirements, or behavior on failure (e.g., if the user is not an owner). For a mutation operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the action. However, it is under-specified given the lack of supplemental information, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two self-explanatory parameters and no output schema, the description is minimally viable. It states the core operation. However, it lacks any guidance on usage, error handling, or prerequisites, making it incomplete in a broader context. Given the simplicity, a 3 is appropriate.
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 schema only provides parameter names ('id', 'user_id') without any descriptions. The description hints that 'user_id' refers to the owner (user) and 'id' likely refers to the project, but it does not explicitly map these parameters or clarify their formats, leaving room for ambiguity.
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 an owner (user) from a nextgen project.' It uses a specific verb and resource, and the name itself (teamleader_projects_remove_owner) aligns perfectly. It distinguishes from siblings like add_owner and unassign by specifying 'owner'.
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 explicit guidance on when to use this tool versus alternatives. With siblings like teamleader_projects_unassign, teamleader_projects_remove_customer, and teamleader_projects_add_owner, the agent gets no hint about when removing an owner is appropriate or how it differs from similar operations. Usage context is only implied by the name.
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 available, the description carries the full burden of behavioral disclosure. It states the operation but does not disclose side effects, whether the action is idempotent, or any requirements on the project or quotation. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the action without any fluff or repetition. It 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?
Given the lack of annotations and output schema, the description is too minimal. It fails to clarify parameter meanings or behavioral consequences, making it insufficient for an agent to invoke the tool confidently without additional inference.
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 explicitly map parameters to the project and quotation IDs. It only hints at the relationship through the verb, leaving 'id' ambiguous without inference.
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 'Ontkoppel' (unlink) and the resource 'offerte' (quotation) from a 'nextgen-project'. This distinguishes it from sibling tools like projects_add_quotation, projects_remove_deal, etc., by specifying the exact 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?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only states the operation itself, leaving usage entirely 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the basic action and optional filtering, but does not mention pagination, ordering, read-only safety, authentication needs, or response format. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It front-loads the verb and resource, making it immediately clear what the tool does. This is exemplary 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 absence of output schema and annotations, the description is too sparse. It does not mention pagination behavior despite having page and page_size parameters, nor does it describe the structure of returned users. For a list operation, this leaves the agent without essential 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?
Schema description coverage is 67% (term and page_size have descriptions, page does not). The tool description only repeats the 'search term' concept already present in the schema, adding no new meaning. It does not compensate for the undocumented 'page' parameter or clarify pagination 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 uses the specific verb 'list' with resource 'users', clearly stating the action and object. It distinguishes itself from sibling tools like teamleader_users_info and teamleader_users_me by focusing on list behavior.
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 teamleader_users_info or teamleader_users_me. There is no mention of exclusions or context, 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 are provided, so the description must disclose behavioral traits. It only states 'Create a new company' without mentioning permissions, idempotency, side effects, or response behavior. This leaves the agent without critical context for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the tool's purpose without extraneous words. It is appropriately concise for a simple create operation.
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?
While the schema covers all parameters, the description lacks contextual information about the return value, error handling, or relationship to other Teamleader entities. With no annotations and no output schema, the description is insufficient for an agent to fully understand the consequences of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for all 7 parameters (100% coverage), providing clear meaning for 'name', 'email', 'tags', etc. The tool description adds no parameter-specific detail, but the schema already covers this adequately, warranting the baseline score of 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 uses the specific verb 'Create' and the resource 'a new company' within 'Teamleader Focus', clearly distinguishing it from sibling tools like teamleader_create_contact. It states the core action in a direct, unambiguous manner.
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 teamleader_create_contact or teamleader_companies_add_tags. The description offers no context, prerequisites, or exclusions, leaving the agent to infer the appropriate 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?
No annotations are present, so the description carries the full burden. It discloses the side effect 'markeert het project als gesloten', but this largely restates the meaning of 'close'. It does not mention reversibility, permissions, or consequences of closing a project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and explicitly notes the side effect, making it appropriately sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter close operation, the description is minimally viable. However, it lacks usage context, parameter clarification, and any mention of prerequisites or behavior after closing, leaving the agent to infer these from the tool name and 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?
The schema has one parameter 'id' with no description (0% coverage), and the tool description does not explain the parameter's meaning or format. The resource name 'project' implies id refers to a project id, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sluit een nextgen-project' uses a specific verb (sluit) and resource (nextgen-project), clearly indicating a close operation. It distinguishes itself from sibling tools like teamleader_projects_reopen, teamleader_projects_delete, and teamleader_projects_update.
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 projects_update or projects_delete. The description does not state prerequisites, conditions for closing, 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 provided, the description carries the full burden of disclosing behavioral traits. It states the action and required field but does not disclose return values, side effects (e.g., project created with what defaults), permissions, or error behavior. The description adds no transparency beyond what the schema already provides, leaving a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core purpose and the key constraint. It contains no filler and earns its place. While it is minimal, it is appropriately sized for a simple create operation with well-documented 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?
For a create tool with a non-trivial schema (including a nested 'extra' object) and no output schema or annotations, the description is incomplete. It does not explain what 'nextgen' means, what the tool returns (e.g., project ID), or how the 'extra' field behaves. The agent would need to infer these from the schema alone, which is insufficient for complete context in a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description. The description's note 'Enkel title is verplicht' reinforces the schema's required field but adds no new meaning. The 'extra' catch-all field is only described in the schema as 'Any other documented projects-v2/projects.create field,' which is useful but not expanded upon. Since the schema fully covers parameters, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Maak een nieuw nextgen-project' (Create a new nextgen project). The verb 'Maak' and the resource 'nextgen-project' explicitly distinguish this from sibling tools like list, update, or delete operations. Even without knowing what 'nextgen' means, the intent 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 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. It does not mention that it is for project creation specifically vs other creation tools, nor does it mention any prerequisites, exclusions, or related tools. The only hint is 'Enkel title is verplicht' which is more about parameter requirements than usage context. This is insufficient for guiding an agent 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states listing and filtering but does not mention pagination, response format, or the constraint that customer_id requires customer_type, leaving an agent without sufficient operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core operation without unnecessary 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 the absence of an output schema and annotations, the description is too sparse. It omits details about pagination behavior, return structure, and the customer_id/customer_type dependency, making it 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents 3 of 4 parameters with descriptions (75% coverage), so the baseline is 3. The tool description adds little beyond the schema, only noting that filtering by customer is optional, which is already implied by the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List subscriptions' with an optional customer filter, identifying a specific verb and resource. This distinguishes it from subscription info/create/update/deactivate sibling tools. 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 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 teamleader_subscriptions_info for single subscription lookup. It only mentions an optional filter, but doesn't address selection criteria 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 only says 'Update'. It does not explain what happens if 'title' is omitted (since 'id' is the only required field), whether the update is partial or full, or any permissions or side effects. The description is too thin for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple update operation and communicates the core purpose efficiently.
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 mutation tool with no annotations and no output schema, this description is incomplete. It does not address the optional 'title' parameter semantics, leaving the agent uncertain about the outcome if 'title' is omitted. The minimal context may be insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both 'id' and 'title'. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies. It does not clarify the behavior when 'title' is optional, but the schema itself is sufficient for basic parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('subscription's title'), clearly distinguishing it from sibling tools like subscriptions_create or subscriptions_deactivate. It precisely states the action and the target attribute, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 that this tool is specifically for changing the title, nor does it reference other subscription update operations like deactivate. There is no context about when this tool should be chosen over siblings.
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 'SIDE EFFECT' note is redundant because 'Create' already implies record creation. With no annotations, the description does not disclose permissions, idempotency, or what happens on duplicate submission. It adds minimal behavioral context beyond the verb.
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 very short and front-loaded, with two phrases and no wasted words. It conveys the core purpose immediately.
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 does not indicate what the tool returns (e.g., ticket ID). It also lacks context about required fields, customer_type choices, or how this relates to other ticket operations. The schema covers parameters, but the tool-level context is thin for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented with individual descriptions. The tool description adds no additional parameter context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new support ticket for a customer'). It distinguishes from sibling tools like tickets_update or tickets_add_message, which operate on existing tickets.
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 is no mention of using tickets_update or tickets_add_message for existing tickets, nor any prerequisites like requiring a customer ID. Usage is implied by 'create' but not explicitly contrasted.
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, but it only states 'SIDE EFFECT: creates a time log record'—essentially restating what 'add' implies. It does not disclose aspects like required fields, idempotency, permissions, or what happens on duplicate submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short clauses totaling 13 words—and immediately communicates the core action. The side-effect note is brief and serves as a useful emphasis without padding.
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 a 100% schema coverage, the description lacks operational context: no return value, no prerequisites, no relationship to timer workflows, and no mention of required subject_id or work_type_id. Given no annotations and no output schema, this minimal description leaves the agent with significant unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters already have clear descriptions (e.g., duration in seconds, started_at ISO 8601). The tool description adds no parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a time tracking entry' with a specific verb and resource, making the tool's function immediately obvious. It also distinguishes from sibling tools like list/update/timer_start/timer_stop by signaling a direct creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like timer_start, timer_stop, or time_tracking_update. The description implies 'use when you want to add an entry' but lacks explicit exclusions or alternative recommendations.
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 behavioral disclosure burden, but it only says 'Create a new calendar event' without mentioning side effects like invitations, confirmations, required permissions, or what the response contains. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, direct sentence with no filler or repetition. It is front-loaded with the verb and clearly identifies the action and target, achieving maximum 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?
The tool has 7 parameters and no output schema, so the description is relatively sparse. However, the schema covers parameter semantics well. Missing context includes return value expectations and how to choose between this and similar session tools, which prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 7 parameters, so the baseline is 3. The description adds no additional parameter explanations beyond what is already in the schema, but it doesn't need to since the schema is thorough.
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'), the resource ('calendar event'), and the system ('Teamleader Focus'). It is specific enough to distinguish from read-only event tools like teamleader_list_events and teamleader_get_event, even though it doesn't explicitly differentiate from teamleader_meetings_create.
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 siblings like teamleader_meetings_create or teamleader_calls_create. There is no mention of prerequisites such as looking up activity_type_id, nor any exclusions or alternative suggestions.
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 single product by id.' It implies a safe read operation but does not disclose response format, potential errors, authorization requirements, or pagination. The description carries the full burden but adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately sized for such a simple get-by-id operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimally acceptable, but it lacks details about the response shape, possible error conditions, or any special behavior. With no output schema and no annotations, a bit more context would be helpful, though the operation is straightforward.
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?
There is only one parameter, 'id', which is already named clearly in the schema. The description adds 'by id' but does not explain what kind of ID it is or any format expectations. With schema description coverage at 0%, the description barely compensates, but the parameter is self-explanatory enough to warrant a baseline score.
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 action ('Get') and resource ('a single product by id'), and 'single' distinguishes it from the sibling teamleader_products_list. This is a specific and unambiguous 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?
The description provideus no guidance on when to use this tool versus alternatives. It does not mention the existence of list or other info tools, nor any prerequisites or context where fetching by id 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 the full burden of behavioral disclosure. It only states the action (remove assignment) without mentioning side effects, whether the project itself is affected, authorization requirements, or irreversibility. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly conveys the core action and object. It avoids fluff and is front-loaded, though it lacks additional structure such as a usage note or example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unassign operation with three parameters and no output schema, the description is minimally adequate. However, it lacks behavioral context (e.g., what happens to the project, whether the user/team is removed from other contexts) and usage guidance, making it incomplete for an agent that needs to reason about side effects.
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 only hints at assignee_type by mentioning 'user or team' and the concept of assignment, but does not clarify that 'id' refers to the project ID or how to obtain assignee_id. The schema's parameter names alone do not convey enough meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Verwijder de toewijzing' - remove the assignment) and the specific resource ('nextgen-project'), with the object being a user or team. This unambiguously distinguishes it from sibling tools like teamleader_projects_assign or teamleader_projects_add_owner.
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 usage is implied: use this when you need to remove a user/team assignment from a project. However, there is no explicit guidance about when not to use it (e.g., vs. remove_owner, remove_customer) or any prerequisites, leaving the agent to infer context from the tool name and description 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 carries the full burden of disclosing behavioral traits. It only states the action (create) and a prerequisite (line items), but omits any information about permissions, side effects, reversibility, or return value. This is similar to the 'Update shared drive settings' example which received a 2 for the same gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only 13 words across two sentences, with no fluff or repetition. It front-loads the core purpose and the key requirement. Every word earns its place, making it a model of 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 moderate complexity (nested line_items array, two required parameters, no output schema), the description is incomplete. It does not mention return values, error conditions, the relationship to the deal, or validation. The agent would have to rely on external documentation or trial-and-error.
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 adds meaning for the line_items parameter ('Provide one or more line items') and ignores deal_id entirely. The schema itself lacks property descriptions, so the tool's parameters are largely unexplained. This is insufficient for an agent to correctly construct a request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('a quotation on a deal'), clearly distinguishing this creation tool from siblings like list, info, update, accept, and send. It also adds the critical requirement of providing line items, which is essential for execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when creating a new quotation for a deal) but does not explicitly state alternatives or exclusions. Sibling tools like update/accept/send make the use case inferable, but there is no explicit 'use this instead of...' guidance, so it remains at an implied level.
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 does not disclose whether the update replaces the entire line_items array or merges with existing items. It also omits side effects like permissions, idempotency, or return values, leaving critical behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is as concise as possible while still conveying the core purpose, making it easy to parse.
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, and the nested structure of line_items, the description is too minimal. It does not explain the replacement semantics, prerequisites (e.g., draft status), or any constraints, leaving the tool under-specified for reliable use.
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 only restates the parameter name 'line items' without adding semantic detail. It fails to clarify that the id parameter identifies the quotation and whether line_items represents a full replacement or an incremental update.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and targets a specific resource ('quotation's line items'), clearly distinguishing it from sibling quotation tools such as create, send, and accept. It is unambiguous about the tool's primary function.
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 guidance or alternatives are provided; the intended use is implied by the verb and resource. It does not state when a quotation can be updated or warn against using create instead, though the purpose is fairly obvious from the name and description.
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 states that the tool lists tickets with optional filters, omitting important behaviors such as pagination (page/page_size), default result limits, ordering, or that it is a read-only operation. Without these details, the agent cannot anticipate response size or any constraints.
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, clear sentence that states the core function and key optional filters. No filler or redundancy, and the most important information is front-loaded. It earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers the basic purpose and optional filters, but it lacks mention of pagination behavior, response format, or any constraints. Since the schema includes page and page_size, the absence of any note about how these are used is a gap. The description is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), with descriptions for customer_id, customer_type, ticket_status_id, and page_size. The description adds little beyond the schema, merely restating that filters are available. It does clarify the high-level purpose of customer/status filters, but does not explain parameter relationships (e.g., customer_id requires customer_type) beyond what the schema already specifies. Baseline 3 applies.
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 a specific verb ('List') and resource ('support tickets'), clearly conveying the tool's function. It mentions optional filters for customer or status, which helps distinguish it from ticket-specific tools like teamleader_tickets_info or teamleader_tickets_create. However, it does not explicitly name alternatives or contrast with sibling list/info tools.
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: this tool lists tickets and optionally filters them, so agents can infer when to use it. However, there is no explicit guidance on when to prefer this over teamleader_tickets_info (for single tickets) or how to handle pagination versus other list tools. The phrase 'optionally filtered' provides some context but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose a key side effect: starting a live timer that must be stopped. However, it does not address other important behaviors such as whether an existing timer is replaced, what happens if called while already running, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then highlighting the side effect. It is compact, scannable, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the most important behavioral consequence (the live timer side effect). However, it lacks information about the return value, how to stop the timer via teamleader_timer_stop, and the distinction from manual time tracking entries. Given the absence of annotations and output schema, additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters, including the dependency between subject_id and subject_type. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a running timer, which is specific and distinct from sibling tools like teamleader_timer_stop. However, it does not elaborate on the timer's relation to time tracking entries, which could further disambiguate from teamleader_time_tracking_add.
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 explicit guidance on when to use this tool versus alternatives. The side effect note implies that the timer must be stopped, but it does not name teamleader_timer_stop as the corresponding action, nor does it mention manual time tracking 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?
With no annotations, the description must fully disclose behavioral traits, but it only states the action. It omits any mention of side effects, permissions, reversibility, or error behavior, which is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant content. It is appropriately concise and well-formed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description covers the basic action but lacks usage guidance, behavioral effects, and return value information. With no output schema or annotations, it is minimally acceptable but could do more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all three parameters, so the description adds no new meaning beyond echoing 'duration' and 'description'. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a time tracking entry and specifies the fields (duration or description). This distinct action and resource set it apart from sibling tools like time_tracking_add and time_tracking_list.
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 any prerequisites. It doesn't mention that adding new entries should use teamleader_time_tracking_add or that an existing entry ID is required, though implied by the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether removal is idempotent, what happens if a tag does not exist, whether it replaces all tags or just the specified ones, or any permission requirements. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key verb and object. Every word earns its place, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple remove-tags tool with only two parameters and no output schema, the description is minimally viable. However, the lack of behavioral details (e.g., error handling, idempotency) and parameter clarification means it is not fully complete, especially since annotations are absent.
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 provides parameter names and types, but the description does not explain what 'id' refers to (presumably the contact ID) or the exact nature of the 'tags' array (e.g., tag names or IDs). With 0% schema description coverage, the description should compensate, but it does not add any parameter-related detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('tags from a contact'), clearly distinguishing it from sibling tools like teamleader_contacts_add_tags and teamleader_companies_remove_tags. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the tool's name and description, but there is no explicit guidance on when to use this tool versus alternatives (e.g., removing from a company vs a contact). No exclusions or prerequisites are mentioned, so it's adequate but not informative.
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 full responsibility for disclosing behavior. It states the invoice is a 'draft', which indicates it is not finalized or booked, but it does not mention permissions, reversibility, side effects, or return behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous content. It immediately communicates the tool's core action and output object.
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 a detailed schema, the description lacks information about what the tool returns, error conditions, or prerequisite relationships (e.g., whether customer_id and department_id must reference existing entities). For a create operation with 8 parameters and no output schema, a one-line description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a meaningful description. The tool description itself adds no additional parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new draft invoice', which immediately distinguishes it from sibling tools that register payments, download, book, or send invoices. It also specifies the context 'Teamleader Focus'.
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 a draft invoice is needed, as opposed to booking or sending. However, it does not explicitly mention alternatives or when not to use this tool, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose any behavioral traits such as error handling, permissions, or read-only guarantees, adding minimal value beyond the basic function.
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, short sentence with no unnecessary words. It is front-loaded with the essential action and resource, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description is minimal but arguably sufficient. However, it omits details about return values, error conditions, or the relationship to other credit note tools, so it barely meets minimum viability.
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. The only parameter is 'id', and the description merely says 'by id', which echoes the schema without adding new meaning or format details.
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'), the resource ('credit note'), and the scope ('single by id'). This distinguishes it from the sibling list tool, teamleader_credit_notes_list.
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 does not explicitly state when to use this tool versus alternatives or provide exclusions. However, the usage is implied by the name and the 'by id' phrasing, suggesting it is for retrieving a specific credit note.
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 mentions the list action and filters, but omits pagination behavior, response format, and any side effects. The description is too minimal to fully inform the agent about how the tool behaves, especially regarding page/page_size parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It clearly front-loads the core action and resource, making it easy to scan.
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 4 parameters, no output schema, and no annotations. The description only explains the filtering options and omits pagination defaults, response shape, or how to navigate results. Given the lack of structured metadata, the description is insufficiently complete for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for 3 of 4 parameters (75% coverage), including page_size max and filter IDs. The description adds the context that invoice and department filters are optional, but does not explain page or page_size semantics, leaving the schema to handle most of the burden. The baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('credit notes'), and defines the optional filters by invoice and department. This distinguishes it from the sibling tool 'teamleader_credit_notes_info' which likely fetches a single credit note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to list credit notes) and mentions optional filters, but it does not explicitly contrast with alternative tools like teamleader_credit_notes_info or say when not to use it. There is no clear exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'get detailed information' without confirming that this is a read-only operation, what happens if the event ID is invalid, or any required permissions. This adds little 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it very concise. However, it is also under-specified, so while it earns points for brevity, it does not use the available space to add valuable context beyond the basics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should indicate what 'detailed information' includes. It does not specify any event fields, potential errors, or prerequisites. For a simple get operation, this is minimally viable but leaves the agent without knowledge of the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, 'id', with 'The event ID' (100% coverage). The description adds no extra meaning about the parameter, such as format or where to obtain the ID, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific event' clearly identifies a retrieval operation for a single event. The verb 'get' and the word 'specific' distinguish it from sibling tools like teamleader_list_events (listing) and teamleader_create_event (creation).
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. It is implied that this is for fetching details after obtaining an event ID via teamleader_list_events, but no alternative names or conditions 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 are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects (e.g., invoice status changes), prerequisites, idempotency, or response format. This is insufficient for a financial mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word contributes to the purpose, making it appropriately concise.
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 should explain the effect on the invoice, required invoice state, and any return value, especially since this is a financial action. The current description is too minimal to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description adds no additional meaning beyond the schema, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Register a payment against an invoice' uses a specific verb and resource, clearly distinguishing it from sibling invoice tools like teamleader_invoices_book or teamleader_invoices_send. It unambiguously states the tool's action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for registering payments but provides no explicit guidance on when to use this tool vs alternatives, no exclusions, and no mention of related tools. The context is clear but under-specified.
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 'optional filtering and pagination', which conveys basic read-only intent but does not disclose response format, default ordering, or any side effects. This is minimal transparency for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('List tasks') and immediately follows with the key optional features. Every word earns its place with no wasted text.
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 list tool with no output schema, the description should explain what the response contains, but it does not. It also lacks any usage guidance or alternative distinctions. The tool is simple, but the description leaves out essential context about return values, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 5 parameters already documented. The description adds no parameter-specific meaning beyond summarizing that filtering and pagination exist, so it does not boost the baseline score of 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 'List tasks from Teamleader Focus', specifying the verb, resource, and scope. It distinguishes this tool from sibling list tools like teamleader_list_contacts or teamleader_list_deals by naming the exact entity (tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that the tool lists tasks, but provides no explicit guidance on when to use it versus alternatives or when not to use it. No alternative tools are mentioned, so usage is implied rather than explicitly directed.
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, but it does not. It fails to mention whether the operation is idempotent, what happens if the customer is already linked, or any required project state. It also provides no information about errors or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without unnecessary words. It is well-structured and front-loaded.
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 simple nature of the operation and the presence of a clear schema with enumerated values, the description is minimally adequate. However, with no annotations and no output schema, more detail on expected behavior or side effects would improve 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?
Schema description coverage is 0%, so the description must compensate. It clarifies that customer_type is contact/company (already in the enum) and that the target is a 'nextgen-project', but it does not explicitly map 'id' to project id or explain 'customer_id'. The parameter meanings are mostly left to inference from the tool name.
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: linking a customer (contact or company) to a nextgen project. It specifies the verb ('Koppel') and the resource ('klant aan een nextgen-project'), and distinguishes from sibling tools like add_deal or remove_customer.
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 through the action phrase but does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. The sibling context suggests it is one of several project-relationship tools, but no guidance 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?
No annotations are present, so the description carries the full burden. It does not disclose pagination behavior, output shape, or explicitly confirm the operation is read-only, leaving the agent to infer from the schema's page/page_size parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the optional filter without 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?
A very short description for a simple list tool, but it omits any information about pagination, the response format, or the distinction between listing and retrieving a single quotation. Given the absence of an output schema and annotations, this is insufficient for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes deal_id and page_size (67% coverage); the description adds no new parameter semantics beyond repeating the deal_id filter and clarifies it is optional. The 'page' parameter remains undocumented, and the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('quotations'), and mentions an optional filter by deal id. This distinguishes it from sibling tools like teamleader_quotations_info, create, and update.
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 as a listing endpoint via the verb 'List' and the optional deal_id filter, but it does not explicitly state when to prefer this over teamleader_quotations_info or other sibling tools, nor does it provide exclusions 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 provided, so the description carries full burden. It simply restates the operation without disclosing behavioral traits such as whether it returns the full ticket, handles errors, or is read-only (though 'get' implies it). It adds no context beyond the verb and resource.
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, focused sentence with no unnecessary words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description is adequate but not complete. It does not mention return value, error behavior, or any details about the ticket object, which are not covered by an output schema or annotations.
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 compensate. It only says 'by id', which restates the parameter name from the schema. It does not clarify the format, requiredness (already in schema), or any additional context about the id 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 the verb 'Get' with a specific resource 'support ticket' and the identifier 'by id'. This distinguishes it from sibling tools like tickets_list (which returns multiple) and tickets_create/tickets_update (which write).
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: you use this when you have a ticket ID and need a single ticket. However, it does not explicitly mention when to use it over alternatives like teamleader_tickets_list, nor does it provide any exclusions or prerequisites.
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 carry the full burden for behavioral transparency, but it only states the basic function. It does not mention pagination behavior (despite having page/page_size parameters), return format, or whether the operation is read-only, though the verb 'list' implies it.
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, clear sentence with no filler. It is front-loaded and easy to parse, earning a perfect score for 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?
For a simple list tool, the description is minimally adequate, but it lacks details about pagination and when the statuses might be used elsewhere. Without annotations or an output schema, the description should provide more context to fully support the agent, but the core purpose is clear.
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 50% (only page_size has a description, page does not), and the tool description adds no parameter details. The phrase 'all available' could even mislead users into thinking pagination is unnecessary, though page/page_size parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (ticket statuses), making it distinct from sibling tools like teamleader_tickets_list or teamleader_tickets_info. There is no ambiguity about what this tool returns.
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 the tool is used to fetch all ticket statuses, but it does not explicitly state when to use it (e.g., before creating or updating a ticket) or contrast it with alternative list tools. It offers no exclusions or alternative references, so usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly notes 'SIDE EFFECT: updates the call status,' which adds some transparency about the mutation, but it does not mention reversibility, permissions, or response format. This is minimal but not empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by a short side-effect note. Every word contributes, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter, the description covers the action and side effect, but lacks information about the expected response or any usage context such as when completion is appropriate. This leaves some gaps, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'id' parameter with 100% coverage, and the description adds no additional semantic meaning to the parameter. The baseline of 3 applies since schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Mark' and resource 'call as completed', clearly distinguishing it from sibling tools like teamleader_calls_list and teamleader_calls_create. 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 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 teamleader_meetings_complete for meetings, nor does it mention any prerequisites or exclusions. The implied usage is obvious from the name, but the description itself does not state 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 must carry the full disclosure burden. It only states the action 'create' without revealing what the tool returns on success, error behavior, idempotency, prerequisites, or any side effects. This is a notable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. It contains no filler or redundant wording, making it appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly documents all parameters, but with no output schema and no annotations, the description lacks essential behavioral context such as return value or success indicators. It is adequate for basic tool selection but insufficient for fully informed invocation without additional assumptions.
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 detailed descriptions for all 8 parameters, achieving 100% coverage. The tool description itself adds no parameter-level information beyond the schema, so it does not enhance what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'contact', and the system 'Teamleader Focus', making the tool's purpose unambiguous. It also distinguishes it from sibling tools like teamleader_update_contact, teamleader_list_contacts, and teamleader_get_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to create a new contact. However, it provides no explicit guidance on when not to use it or alternatives (e.g., for adding tags separately via teamleader_contacts_add_tags), and does not mention required fields like first_name and last_name beyond what the schema already shows.
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, but it only states the basic function. It does not mention pagination behavior, response format, error cases, or any side effects. The presence of page/page_size parameters in the schema is not reflected in the description, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the purpose and required inputs. No filler or redundant content, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is adequate but incomplete. It covers the core purpose and required parameters, but lacks detail on pagination, return payload, and usage boundaries. With no output schema, the description could reasonably be expected to mention what files list returns, but it remains minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so baseline is 3. The description adds examples of subject_type values (contact, company, deal), enriching the schema's generic description, but it does not elaborate on page/page_size semantics. The required-parameter statement duplicates schema information, offering minimal additional value beyond the examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: "List files linked to a subject" with specific examples of subject types. It is distinct from sibling tools like teamleader_files_upload and teamleader_files_download, which handle different file operations.
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 states that subject_type and subject_id are required, giving clear usage prerequisites. However, it does not explicitly contrast this tool with alternatives (e.g., upload/download) or provide when-not-to-use guidance, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool supports filtering and pagination, which is useful, but it does not explicitly state that this is a read-only operation, nor does it describe any authentication requirements, rate limits, or response behavior beyond listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'List calendar events from Teamleader Focus with optional filtering and pagination'. It is concise, contains no redundancy, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description would need to explain what the response contains, but it does not. The parameter details are covered by the schema, yet the description leaves the return format and pagination behavior unstated, making it adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all six parameters, so the baseline is 3. The description only summarizes this as 'optional filtering and pagination', adding no new meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists calendar events from Teamleader Focus, which is a specific verb+resource combination. It distinguishes from sibling tools like teamleader_get_event (single event) and teamleader_create_event (create), and from other list tools like meetings_list and calls_list.
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 mentions optional filtering and pagination, implying it is for reading multiple events, but provides no explicit guidance on when to use this tool versus alternatives such as teamleader_get_event for a single event. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions optional search-term filtering but does not disclose pagination behavior, default page sizes, return format, or any potential side effects. For a list operation this is a moderate gap, as the schema exposes page and page_size parameters without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of six words. Every word adds meaning, and there is no redundancy or filler. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with three optional parameters and no output schema. The description provides the essential purpose but omits pagination behavior and return-value expectations. Given the presence of structured schema fields, the description is minimally viable but could be richer to fully orient an agent, especially without annotations or output schema.
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 minimal value beyond the schema: it clarifies that search-term filtering is optional, aligning with the schema's zero required parameters. However, it does not explain the 'page' parameter and only partially reinforces 'page_size'. With schema description coverage at 67%, the description compensates slightly but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's core function with a specific verb and resource: 'List products, optionally filtered by search term.' It clearly distinguishes from related sibling tools like teamleader_products_info (which retrieves a single product) and teamleader_product_categories_list (which lists categories, not products).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving multiple products based on the verb 'List,' but does not explicitly explain when to use this tool versus alternatives such as teamleader_products_info or teamleader_product_categories_list. There is no explicit when/when-not guidance, only the inherent implication from the tool name and phrasing.
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 states the action and filters, omitting pagination behavior, default page sizes, sorting, or output structure. This is a read-only operation, but the lack of pagination details is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. No wasted words; it effectively communicates the core purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with four parameters and no output schema, the description is minimal. It doesn't mention pagination, return value structure, or that results are likely a list of project objects. The schema hints at pagination via page/page_size, but the description could be more complete for an agent to fully understand expected results.
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 mentions 'search term or status', mapping to the term and status parameters and indicating they are optional. However, it doesn't add meaning for page and page_size beyond the schema, and the schema already covers 75% of parameters with descriptions. The description adds marginal 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 the action ('List') and the resource ('nextgen projects'), with optional filters. It distinguishes itself from sibling project tools like teamleader_projects_info and teamleader_projects_create by being the list operation.
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 this tool is for listing projects with optional filters, but it doesn't explicitly state when to use it over alternatives like teamleader_projects_info or provide exclusions. It gives basic context but no explicit guidance on alternative 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 responsibility for behavioral disclosure. It only states 'Get', which implies a read operation, but it does not indicate what the response contains, whether an invalid id errors, or any authentication or rate-limit considerations. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the verb and resource, making it highly efficient and readable. Every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is minimally adequate. It states what the tool does, but it does not elaborate on the return structure or any edge cases (e.g., missing quotation). Given the absence of an output schema, a bit more detail could improve completeness, though it is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single required 'id' parameter with no description. The description explicitly says 'by id', clarifying that the parameter is the quotation identifier. However, it provides no format constraints, examples, or additional context, so it only partially compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'a single quotation', explicitly narrowing scope to a single item by id. This distinguishes it from sibling tools like teamleader_quotations_list (multiple) and teamleader_quotations_create (creation).
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 a specific quotation id is known, but it does not explicitly mention alternatives such as using the list tool for multiple quotations. The 'by id' qualifier provides some context, but there is no clear when-to-use versus when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey side effects, but it only says 'Update', which is a mutation hint. It does not disclose permissions, partial-update behavior, or return value, leaving key behavioral traits unspecified.
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?
One sentence, front-loaded, and no filler. It is perfectly concise for the information it conveys.
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 a simple 3-parameter schema and no output schema, the description is understandable for basic use. However, the lack of annotations and behavioral details (e.g., whether fields are overwritten, response shape) leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with individual descriptions (ID, subject, status ID) at 100% coverage, so the baseline is 3. The description adds minimal extra meaning beyond the schema by linking 'subject or status' to the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') plus resource ('ticket') and names the mutable fields ('subject or status'), clearly distinguishing it from sibling tools like tickets_create or tickets_add_message.
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 is given on when to use this versus alternatives; it only states what the tool does. The context implies use for modifying existing ticket fields, but there are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List' which implies a read-only operation, but it does not disclose pagination behavior, default ordering, result structure, or any filtering constraints beyond user_id. For a list tool, significant behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential action and scope directly, making it easy to parse and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (3 optional params, no output schema), the description is adequate but leaves out details such as whether results are paginated by default, how to handle large result sets, or what fields are returned. It is complete enough for basic use but lacks the context that would be expected for a fully self-sufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (user_id and page_size have descriptions, page does not). The description adds the word 'optionally' for user filtering, which aligns with user_id, but it does not explain page or page_size beyond what the schema already provides. The added value over the schema is minimal, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List time tracking entries, optionally filtered by user' clearly states the verb and resource, and the optional user filter distinguishes it from other time tracking tools like add, update, or timer start/stop. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when listing time tracking entries), but it provides no explicit guidance about when not to use it or alternatives such as fetching specific time entries via other tools. No exclusions or alternative recommendations are given, so the guidance is only implicit.
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 states 'Get', which implies a read-only operation, but does not mention error behavior, authentication requirements, or response characteristics. This is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and no output schema, the description is minimally sufficient but lacks context about return values or error cases. Given the absence of annotations and output schema, more detail could be provided to make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with zero description coverage. The phrase 'by id' clarifies that id is the user identifier, but does not provide format, constraints, or examples. It adds a small amount of meaning beyond the schema but does not fully compensate for the lack of parameter 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 'Get a single user by id' uses a specific verb and resource, clearly distinguishing itself from sibling tools like teamleader_users_list and teamleader_users_me. It unambiguously states the action and the target entity.
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 you have a user id and need a single user, but it does not explicitly mention alternative tools for list or 'me' operations, nor does it state when not to use this tool. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions that filtering is optional, which implies unfiltered calls when no filter is provided. However, it does not disclose pagination behavior, default page size, or return structure. The read-only nature is implied by 'List' 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that conveys the core purpose and key option. There is no redundant wording or unnecessary detail, making it appropriately concise.
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 no output schema and no annotations, the description lacks essential context. It does not explain the return format, pagination options, or the dependency between filtering parameters. The agent would need to infer too much about how to correctly invoke the tool with filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with three of four parameters described. The description adds only the concept of customer filtering, which is already present in the schema via customer_id and customer_type descriptions. It does not clarify the missing 'page' parameter or the requirement to use customer_id and customer_type together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'calls', and mentions an optional filter by customer. This distinguishes it from sibling tools like teamleader_calls_create and teamleader_calls_complete, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool lists calls and can be filtered by customer, but does not explicitly state when to use it vs alternatives. It also fails to mention the mutual dependency between customer_id and customer_type, which is crucial for correct invocation. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'get' (a read operation), but adds no context about return format, error conditions, authorization requirements, or limitations. For a read tool with no annotations, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single required parameter, no output schema, no annotations), the description is fairly complete for selecting and invoking the tool. It explains what the tool does and implies the ID parameter. However, it does not mention what 'detailed information' includes or any caveats, so it is not a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'id' with description 'The contact ID', and schema coverage is 100%. The description's 'specific contact' aligns with 'id' but adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific contact' clearly states the verb (get) and resource (contact), and distinguishes itself from sibling tools like teamleader_list_contacts (list), teamleader_create_contact (create), and teamleader_update_contact (update). The phrase 'specific contact' implies retrieval by ID, which 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this when you need detailed data for a particular contact identified by ID, versus listing contacts or modifying them. However, there is no explicit statement about when to use this tool versus alternatives, nor any exclusions or prerequisites.
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 mentions 'optional filtering and pagination', which is already visible in the schema. It does not clarify whether this is a safe read-only operation, how pagination behaves beyond schema defaults, or what the response structure will be—especially with no output schema present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. Every word contributes value; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only list tool, the description plus schema is nearly sufficient. It clearly names the resource and includes schema-defined filtering/pagination options. The absence of an output schema means return format isn't specified, but that's not the description's obligation. Minor gaps remain around default behavior (e.g., sorting) and safety profile, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with detailed descriptions for all 6 parameters, so the description does not need to repeat them. It adds only the generic phrase 'optional filtering and pagination', which adds no specific meaning beyond the schema's per-parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'companies from Teamleader Focus', making the tool's collection-oriented purpose obvious. It distinguishes itself from sibling tools like 'teamleader_get_company' (single company) and 'teamleader_list_contacts' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving multiple companies with filtering and pagination, but it does not explicitly state when to use this tool over alternatives like get_company or list_contacts. No exclusions or alternative references are provided, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly notes 'SIDE EFFECT: verwijdert het project onomkeerbaar' (irreversible deletion), which is a critical behavioral fact. However, it does not mention other potential side effects like cascading deletes or permission requirements, though the irreversibility note is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and immediately followed by the key side effect. Every word is informative, and there is zero waste. It is a model of concise, readable tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the essential action and irreversibility. However, it does not specify what the return value looks like (e.g., success message, deleted object), nor does it warn about any prerequisites or consequences beyond deletion. Given the simplicity, this is adequate but has clear gaps around post-condition behavior and distinction from close/reopen.
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 defines one parameter 'id' as a string, but schema description coverage is 0% and the description does not mention the parameter at all. The description therefore adds no semantic meaning beyond what the schema provides; the agent must infer that 'id' is the project identifier from the tool name and 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 'Verwijder een nextgen-project' clearly states the action (delete) and resource (nextgen-project), distinguishing it from sibling tools like projects_update, projects_close, and projects_duplicate. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 projects_close (which is non-destructive) or projects_reopen. While the SIDE EFFECT note warns of irreversibility, it does not explicitly frame this as a last-resort action or suggest when deletion is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It explicitly states the side effect ('marks the quotation accepted') and the difficulty of undoing it, providing important safety context. However, it omits other potential behaviors like return values 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and the key side effect. Every word adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core action and side effect. However, it lacks information about the return value, prerequisites, or how it fits into the quotation workflow, leaving the description partially 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 schema has a single 'id' parameter with no description, and schema coverage is 0%. The description does not explicitly clarify that 'id' refers to the quotation's ID or any format requirements. Since coverage is low, the description fails to compensate for the missing 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 uses a specific verb 'Accept' and a resource 'quotation,' making the action unambiguous. It distinguishes from sibling tools like send or update, and the side-effect note further clarifies its unique 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?
The description provides no guidance on when to use this tool versus alternatives such as teamleader_quotations_send or teamleader_quotations_update. There is no mention of prerequisites or situations that call for acceptance.
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 states the operation without elaborating on the return format, side effects (e.g., read-only nature), or any prerequisites. This is minimally transparent for a simple get operation but lacks useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that immediately states the tool's purpose. There is no wasted text, and it is front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description is adequate. It lacks an explicit mention of the return value (e.g., a user object), but given the absence of an output schema and the simplicity of the operation, this is a minor gap. The description covers the essential purpose completely.
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, so the schema fully covers everything. According to the rubric, a 0-parameter tool gets a baseline of 4. The description does not need to add parameter details, 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 'Get the currently authenticated user' uses a specific verb 'Get' and a clear resource ('currently authenticated user'), making it distinct from sibling tools like 'teamleader_users_list' and 'teamleader_users_info' which operate on either all users or a specific user by ID.
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 does not mention that this is the appropriate choice when you need the profile of the logged-in user specifically, nor does it exclude other use cases. The description simply 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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It simply restates the action ('Unregister a webhook URL') without detailing side effects, idempotency, error conditions, or whether the URL is removed entirely if no event types remain. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the action and scope. Every word earns its place; there is no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter mutation tool with full schema coverage, the description is largely complete. It clearly states what unregistration does, but lacks explicit mention of edge cases (e.g., what happens if URL is not registered) and doesn't point to the related register tool. Minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('The webhook URL to unregister' and 'List of event types to unsubscribe from'), so the description adds no new meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Unregister' with the resource 'webhook URL' and scopes it to 'given event types'. This clearly distinguishes it from sibling tools like teamleader_webhooks_register and teamleader_webhooks_list.
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?
Usage context is implied as the inverse of registration, but there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites (e.g., URL must be currently registered). The sibling names hint at the relationship but the description does not state 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 behavioral disclosure burden. It only states 'Create' and required fields, with no mention of side effects, permissions, reversibility, or response format. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, and no filler. Every piece of text adds information: action, required fields, and a helper tool reference. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description does enough by identifying required fields and pointing to a helper for a key parameter. The schema already describes each parameter in detail. It falls short only in not describing the return value or potential errors, but for a create tool this is acceptable.
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 100% coverage for parameters, so the baseline is 3. The description adds extra value by calling out the three required properties (title, due_on, work_type_id) and providing a specific lookup workflow for work_type_id, which is not fully explicit 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 'Create a new task in Teamleader Focus' with a specific verb and resource. It also lists the three required fields, making the purpose unambiguous. However, it does not explicitly distinguish this from sibling create tools, relying on the name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage guidance by stating required fields ('title, a due date and a work type') and directing users to teamleader_work_types_list to obtain a valid work_type_id. It covers prerequisites but does not discuss when not to use or alternatives (e.g., teamleader_list_tasks for reading).
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 full burden. 'Get' implies a non-mutating read with no side effects, which is adequate for a simple getter. However, it does not mention any error conditions, permissions, or return format, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, eight words, front-loaded with the verb. No redundancy or filler.
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?
This is a simple one-parameter getter with no output schema. The description adequately identifies the operation but leaves 'detailed information' vague; it could specify what fields are returned. Still, it is minimally sufficient for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single 'id' parameter described as 'The company ID'. The description adds no further meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific company' clearly states the action (get) and the resource (company details). The word 'specific' differentiates it from list_companies, and 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?
Usage context is implied: use when you need details for a known company ID. No explicit alternatives or exclusions are mentioned, but the sibling tools (list_companies, create_company) make the intended use inferable.
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 says 'Get' which implies a read operation, but it does not explicitly state that it is non-destructive, idempotent, or what happens if the deal does not exist. It lacks any additional context such as permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that conveys the essential purpose without any redundant words. It is front-loaded with the verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description is minimally sufficient. 'Detailed information' hints at the return value, but it does not explicitly describe the response structure or error scenarios. It is not comprehensive, but adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter, which is described as 'The deal ID'. The description does not add any additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('specific deal'), making it clear that this tool retrieves a single deal's details. It distinguishes itself from sibling tools like list_deals, create_deal, and update_deal by focusing on individual deal information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific deal' implies the user already has a deal ID and wants detailed data, distinguishing it from listing or creating deals. However, it does not explicitly name alternative tools or state when not to use it, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully carry the burden. It discloses that filtering and pagination are optional, indicating a read-like operation, but does not mention the absence of mutations, default pagination behavior beyond the schema, sorting, or any edge cases. The behavioral depth is minimal but not misleading.
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?
A single sentence, front-loaded with the primary action, and free of redundant detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks additional context that would aid invocation, such as return format, sorting behavior, or explicit notes on pagination defaults. Given there is no output schema, some description of expected output would improve completeness. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters, so the baseline is 3. The description's mention of 'filtering and pagination' is a high-level summary of the parameters without adding new semantics or clarifying relationships. It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List contacts') and the resource ('Teamleader Focus'). It also specifies the scope with 'optional filtering and pagination', distinguishing it from single-contact retrieval tools like teamleader_get_contact. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing contacts with optional filters, but it does not explicitly state when to prefer this over alternatives such as teamleader_get_contact or teamleader_list_companies. There are no exclusions or alternative tool references, so guidance is merely implied rather than explicit.
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 says 'List' and mentions required parameters, but doesn't explain pagination (page/page_size), return format, or whether it's a read-only operation. Since no output schema exists, the lack of return-value details is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and scope. No filler or redundancy; every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the core requirement and examples. However, it omits pagination behavior, sort order, and return structure. Since there is no output schema, the description should explain what the response looks like, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with descriptions for subject_type, subject_id, and page_size. The description repeats the subject_type examples already in the schema, adding no new semantic value. The page parameter is undocumented in both places. Baseline of 3 is appropriate since the schema mostly covers parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List notes') and the resource scope ('linked to a subject') with concrete examples. It distinguishes from sibling tools like teamleader_notes_create by focusing on the listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that subject_type and subject_id are required, giving clear context for when to use the tool. It doesn't explicitly mention alternatives or exclusions, but there is no competing notes-list sibling, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a webhook is registered, with no mention of required permissions, potential side effects (e.g., whether existing registrations are overwritten), idempotency, or error behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's action. It includes useful examples without unnecessary detail. Every word serves a purpose, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 2 parameters, but the description omits important context such as what the API returns upon success (e.g., a webhook ID), whether duplicate registrations are handled, and any authentication prerequisites. This is adequate for basic understanding but leaves gaps that an agent may need for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters completely: url is an HTTPS URL for POST requests, and types is a list of event types with an example. The description's example of event types duplicates what is in the schema, adding no new meaning. Since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the action verb 'Register' and identifies the resource as a webhook URL for specific event types. Concrete examples ('deal.created', 'invoice.booked') are provided, making the purpose unmistakable. It clearly distinguishes from sibling tools like teamleader_webhooks_list and teamleader_webhooks_unregister, since registration is a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for subscribing to webhook events, and the context is clear enough that an agent would know to use it for setting up webhooks. However, it does not explicitly mention alternatives or when not to use it (e.g., when to use list or unregister instead). No exclusions are stated, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the return value is a temporary URL, which is a key behavioral trait. However, it does not mention expiration duration, access requirements, or potential side effects, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It clearly states the action, target, and output without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is sufficiently complete. It tells users what to provide (file ID) and what they will receive (temporary download URL). Minor details like URL expiry are not defined, but the tool's simplicity limits the need for further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the single parameter ('ID of the file to download'), with 100% coverage. The tool description adds little beyond the schema, simply restating the ID's purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('temporary download URL for a file'), and clearly indicates the required input ('by its ID'). This distinguishes it from sibling tools like teamleader_files_list (which lists files) and teamleader_files_upload (which uploads files).
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 you have a file ID and need a download URL. However, it does not explicitly mention alternatives (e.g., use teamleader_files_list to find IDs) or when not to use this tool. Guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It does disclose the side effect ('updates the meeting status'), which is helpful. However, it lacks other behavioral details such as idempotency, permissions required, or behavior if the meeting is already completed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with exactly two short sentences. It states the primary action and the side effect without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation tool with no output schema, the description covers the essential context: what it does and its side effect. It could be argued it should mention idempotency or return values, but given the simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter ('Meeting ID to complete'), so the description adds no additional parameter meaning. A baseline of 3 is appropriate since the schema handles the semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark a meeting as completed') and the resource (meeting), distinguishing it from sibling tools like teamleader_meetings_create and teamleader_meetings_list. The side effect is also noted, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the action ('complete a meeting') but there is no explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. It does not mention exclusions, e.g., that it cannot be used for calls (which has a separate complete 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 are provided, so the description carries the full burden of behavioral disclosure. It only states the creation action and linkage, without addressing authorization, side effects, or what happens upon success or failure. This leaves the agent with little beyond the obvious write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and object, with no wasted words. The parenthetical examples add useful clarity without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity three-parameter create operation, the description adequately covers the core purpose and linking concept. The absence of an output schema and annotations means return/error behavior is not explained, but this is a minor gap given the straightforward nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes all three parameters at 100% coverage, so the description does not need to repeat them. The mention of 'contact, company, deal' reinforces the subject_type examples but adds no new semantic detail beyond what the schema already provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with a clear resource ('a note') and adds the key constraint that it is linked to a subject, with examples like contact, company, and deal. This distinguishes it from sibling tools such as teamleader_notes_list and other create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when creating a note tied to a contact, company, or deal. It does not explicitly state when not to use it or name alternative tools, but no direct sibling alternative for note creation exists, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly calls out the side effect: 'SIDE EFFECT: emails the customer.' This is a significant behavioral trait beyond the parameter schema. However, it does not detail other potential behaviors such as whether the quotation status changes or whether permission requirements apply.
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 that immediately states the action and side effect. It is perfectly front-loaded and concise, with no wasted words. Every part of the sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send operation with no output schema, the description covers the core action and side effect. However, it leaves out potential details like whether the quotation status is updated after sending, or if the email includes a link versus an attachment, which could be relevant for an agent deciding between this and nearby 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 low (33% of parameters have descriptions, only recipients_to). The description does not compensate by explaining the id or subject parameters. The agent must infer that id refers to the quotation and subject to the email subject, which could be ambiguous.
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: 'Send a quotation by email' with a specific verb and resource. It distinguishes from sibling tools like list, info, create, update, and accept by explicitly specifying the sending action.
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 the user wants to email a quotation, but it does not explicitly state when to use this over alternatives or provide exclusions. There is no mention of when not to use it or how it compares to similar send operations like invoices_send.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully highlights the side effect of stopping future invoicing, which adds important context beyond merely saying 'deactivate'. However, it does not disclose other relevant behaviors such as irreversibility, required permissions, or impact on existing invoices.
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 remarkably concise: one sentence with a clear action and an explicit side effect. It is front-loaded with the verb and resource, and every word adds value. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema, no annotations), the description covers the essential purpose and the key side effect. It is adequately complete for the complexity level, though it could optionally mention reversibility or permissions. Overall, it provides enough context for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'id' with a clear description ('The subscription ID to deactivate'). The tool description adds no additional parameter details, so it does not go beyond the schema. Baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'deactivate' and the resource 'subscription', and uniquely identifies the scope by adding the side effect of stopping future invoicing. This distinguishes it from sibling tools like subscriptions_update or subscriptions_info, which relate to other actions on subscriptions.
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 side effect 'stops future invoicing' implies the appropriate context for use, but the description does not explicitly state when to use this tool versus alternatives like subscriptions_update or when not to use it. There are no exclusion criteria or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. 'List' implies a read-only operation, which is disclosed, but the description does not mention return format, pagination behavior, or any side effects. It is minimally transparent, adding no detail beyond the inherent meaning of 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It is front-loaded with the verb, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two optional pagination parameters and no output schema, the description is nearly complete. It states the core purpose clearly. A complete explanation of return structure would require an output schema, but the description could have added a note about pagination or the webhook object fields. Given the simplicity, it is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (page_size has a description, page does not), and the description adds no parameters details. Page is self-explanatory as a number, and page_size is partially documented with 'max 100'. The description neither compensates for page's lack of description nor clarifies pagination semantics. This sits at the mid-coverage 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 'List registered webhooks' uses a specific verb (List) and resource (registered webhooks), clearly distinguishing it from sibling tools that register or unregister webhooks. It is unambiguous and directly states the action and target.
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. However, the usage is implied by the verb 'List' and the resource 'webhooks', and the siblings include register/unregister. It's clear that this is for viewing existing webhooks, but no explicit when/how guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that filtering and pagination are supported, which is a minimal behavioral trait. However, it does not mention return format, ordering, default page size limits (beyond schema), authentication needs, or any other operational behaviors. This is adequate for a basic read-only list tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and object. It contains no redundant words and conveys the essential purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is somewhat minimal. It clearly states the purpose and capabilities but does not describe the response shape, default behaviors, or any relevant limitations beyond what the schema covers. There are clear gaps given the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all six parameters with descriptions, so schema coverage is 100%. The description adds no extra meaning beyond the schema, merely stating 'optional filtering and pagination' as a summary. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List deals/opportunities from Teamleader Focus'. It clearly distinguishes from single-deal operations like get_deal, create_deal, and update_deal, and the mention of optional filtering and pagination further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for listing deals with optional filters and pagination. However, it does not explicitly name alternatives or state when-not-to-use cases. The sibling tool names (e.g., get_deal for single deal) imply the distinction, but it is not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that filtering and pagination are supported, which is useful, but it does not mention the read-only nature, response format, or any pagination details beyond what the schema already provides. The behavior is minimally transparent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. Every word adds value, and it is appropriately sized for a straightforward list operation.
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?
Despite 7 optional parameters and no output schema, the description is very brief and does not explain response contents or default behavior. It would benefit from stating that it returns a paginated list of invoices or how to use filters effectively. The schema covers parameters, but overall context is incomplete for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not repeat parameter details. It adds only a high-level phrase 'optional filtering and pagination', which restates the schema. Baseline 3 is appropriate as the description adds little semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), resource ('invoices'), and system ('Teamleader Focus'), and notes optional filtering and pagination. This distinguishes it from siblings like teamleader_get_invoice (single invoice) and teamleader_create_invoice (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving multiple invoices with optional filters and pagination. It does not explicitly mention alternatives or exclusions, but the list-vs-get distinction is clear from the verb and sibling context. Lacks explicit 'when not to use' guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior on its own. The word 'Get' implies a read-only action, but it does not disclose what happens if the ID is invalid, rate limits, or return structure. This meets the minimum but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence front-loaded with the action and resource. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-id tool, the description covers the basic purpose, but the term 'nextgen' is unexplained, and there is no information about response contents, error handling, or prerequisites. Given the low complexity, it is minimally sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only an 'id' string with no description (0% coverage), so the description's 'by id' offers minimal clarification that the parameter is the project identifier. It does not explain format, source, or type beyond what the schema already shows, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'nextgen project' and the qualifier 'by id', clearly distinguishing it from list/create/update tools among siblings. It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a single ... by id' clearly implies this tool is for retrieving one specific project when an ID is available, contrasting with list operations. However, it does not explicitly name alternatives or mention when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns 'SIDE EFFECT: creates recurring invoicing for the customer', which is critical behavioral context beyond a simple 'create'. However, it doesn't disclose other traits like whether the subscription can be modified/deactivated later, or whether the creation can be undone. The side-effect disclosure is strong but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a clear purpose and a crucial side-effect warning. Every word earns its place. It could arguably be a single sentence, but the side-effect is properly highlighted. This is appropriately sized for a creation tool with significant side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 required params, nested line_items), the description is minimal but the schema carries the parameter documentation burden. The side-effect disclosure is essential context. However, there's no output schema, and the description doesn't mention what a successful response contains (e.g., the new subscription ID) or any failure modes. Still, for a creation tool with full schema coverage, the critical business side-effect is covered, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 8 parameters have descriptions in the schema. The description adds none beyond that; it simply restates the purpose. While the schema's parameter descriptions are adequate, the description doesn't elevate them (e.g., explain relationships between billing_periods and billing_unit, or the consequences of line_items). Baseline 3 applies since schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new subscription' with a specific resource, and the title/name also align. It additionally notes a clear business side-effect (recurring invoicing), which distinguishes it from other creation tools like create_contact or create_invoice. The verb 'create' and resource 'subscription' are explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when creating a subscription), but provides no guidance on alternatives or exclusions. Sibling tools like subscriptions_update, subscriptions_deactivate, or subscriptions_list exist, but the description doesn't state when to prefer this over them. However, the side-effect warning implicitly signals that this is a consequential action, which is some usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly calls out the side effect ('books the draft into accounting and assigns a number') and notes it is 'not freely reversible'. This is valuable behavioral context especially since no annotations are provided. It could further disclose permissions or edge cases, but it covers the key irreversibility aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, followed by a clear side-effect warning. Every word earns its place, with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and no annotations, the description covers the main action, side effect, and irreversibility. It lacks explicit return value information, but the operation is straightforward enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% meaningful descriptions for both parameters ('id' and 'on'), so the baseline is 3. The description does not add additional parameter-level detail beyond the schema, but it doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Book') and resource ('draft invoice'), clearly distinguishing it from sibling tools like send or register payment. It also explains the outcome (assign a number), which aligns with the tool's name and purpose.
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 the tool is for draft invoices and books them into accounting, but it does not explicitly state when to use it vs. alternatives (e.g., not for sending or registering payments). The context is clear but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the URL is 'temporary', which is useful, but does not elaborate on expiration, authentication requirements, or potential side effects, leaving gaps for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose without redundant information, earning top marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with no output schema and no annotations, the description adequately explains the return value (temporary URL) and the format parameter. It does not cover edge cases like errors or URL expiration duration, but these are not critical for basic usage understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'id' and 'format' already described in the input schema. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a temporary download URL for an invoice', distinguishing it from sibling tools like teamleader_files_download and other invoice operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the tool's purpose, making it obvious when to use it (to download an invoice). It does not explicitly mention alternatives or exclusions, but the specificity of the tool name and description provide sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the key side effect ('emails the customer'), which is important for a send operation. However, it does not mention other behavioral traits like status change or failure modes, but the side effect disclosure adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence plus a side-effect note. It is front-loaded and every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send operation with fully documented parameters, the description covers the essential purpose and side effect. It does not explain return values, but no output schema exists and the operation's outcome is straightforward. It is reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for id, subject, and recipients_to.
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 (send) and resource (invoice), specifying the recipients. It distinguishes from sibling tools like download or register payment by using the verb 'send' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for emailing invoices but does not provide explicit guidance on when to use this tool versus alternatives such as teamleader_invoices_download. No exclusions or alternative tool mentions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states 'SIDE EFFECT: posts a message on the ticket thread', which is significant for a mutation tool. However, it does not mention authentication, irreversibility, or potential notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The side-effect note is front-loaded and enriches the purpose without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description adequately covers the action, resource, and a key side effect. It could mention that the ticket must exist or that the message appends to the thread, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for ticket_id and body. The tool description adds no extra parameter meaning beyond what the schema already provides, so the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a reply/message to a ticket', using a specific verb and resource. This distinguishes it from ticket creation and ticket updates, which are present as siblings.
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 side-effect note implies usage for posting messages, but there is no explicit when-to-use guidance or comparison with alternatives. Siblings like tickets_update could be confused, but the purpose wording is self-explanatory enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly discloses the side effect: 'stops the timer and creates a time tracking entry.' This is the key behavioral information, though it doesn't cover edge cases like what happens if no timer is running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the action, the second adds the critical side effect. No fluff, no repetition, front-loaded with the verb phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with only two parameters and no output schema, the description covers the essential behavior and side effect. It doesn't address edge cases, but given the low complexity, it is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both parameters (id required, ended_at with format and default). The description adds no additional parameter context, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Stop a running timer.' It also highlights the side effect of creating a time tracking entry, which distinguishes this tool from teamleader_timer_start and other time tracking tools.
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?
Usage is implied by the name and the presence of sibling timer_start, but there is no explicit 'when to use' or 'when not to use' guidance. The side effect note hints at using this when you want to stop and record time, but no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It correctly implies a read-only listing operation with 'List work types,' but it does not disclose pagination behavior, default page size, or response structure. The mention of finding an ID adds some context, but more behavioral detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers both what it does and why you would use it, which is sufficient for correct invocation. It lacks an explicit mention of return format, and given no output schema, a brief note on what the response contains would improve completeness. However, the stated purpose and use case are enough for most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (term and page_size have descriptions, page does not). The description adds the context of 'finding a work_type_id,' which helps interpret the purpose of parameters, but it does not add new parameter-level syntax or details beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List work types,' which clearly identifies both the action (list) and the resource (work types). It further distinguishes itself by stating the purpose: 'Use this to find a work_type_id for creating tasks or time tracking,' making it clear how this tool differs from other list 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this to find a work_type_id for creating tasks or time tracking.' This gives a clear context for invocation, though it does not mention alternatives or when not to use it, which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses that only provided fields are changed, which is a key behavioral trait distinguishing it from a full replace. However, it does not discuss other behaviors like error handling, permissions, or return value, but for a partial update this is significant.
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?
One concise sentence, front-loaded with the action, no redundant wording. Perfectly sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and update semantics. However, there is no output schema and no annotation protection, so the description could have mentioned what the tool returns or any prerequisites. Still, given the schema covers parameter details, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond noting that only provided fields are updated, which is already implicit in the schema. The 'extra' parameter is described in the schema, and the description does not elaborate on it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update een nextgen-project' (update a nextgen project), specifying a specific verb, resource, and scope. It distinguishes from sibling tools like create, delete, close, etc., by focusing on updating existing project fields, and adds the partial-update nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Enkel meegegeven velden worden aangepast' (only provided fields are changed) provides clear context for when to use this tool: to update specific fields without overwriting others. It does not explicitly name alternatives or exclusions, but the partial-update semantics imply when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that this step does not upload the bytes but only returns a URL for a subsequent PUT, which is a critical behavioral trait. It could add more about auth requirements or link completion, but the core side-effect (no bytes uploaded here) is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One well-structured sentence that front-loads the main purpose (step 1, returns upload URL) then provides essential supplementary context (bytes are PUT out of band). No fluff, every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-step tool with no output schema, the description is complete: it explains what is returned, the second step, and the required inputs. It also implicitly differentiates from sibling file tools. No critical information is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds some contextual meaning ('link the file to' and 'intended file name') but largely repeats schema details. It doesn't significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is 'Step 1 of a two-step file upload flow' and that it returns an upload URL/location, which is a specific verb+resource outcome. It also distinguishes itself from sibling file tools (list/download) by focusing on the upload initiation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by explaining the two-step flow: call this to get a URL, then PUT bytes to that URL out of band. It clearly implies when to use this tool (start an upload) without explicitly naming alternatives, but the step-based guidance is strong. It lacks explicit exclusions but is still clear.
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:

[![boostu-teamleader-mcp MCP server](https://glama.ai/mcp/servers/boostuagency/boostu-teamleader-mcp/badges/card.svg)](https://glama.ai/mcp/servers/boostuagency/boostu-teamleader-mcp)

Score Badge

Copy to your README.md:

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

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