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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.