accelo

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, but the description reinforces it with an enforcement-level constraint ('READ-ONLY — only GET is allowed') and adds behavioral context the annotations lack: the response envelope { meta, response }. It doesn't cover auth requirements or rate limits, keeping it below a 5.

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?

Front-loaded with the tool's nature, then the constraint, then the parameter format with examples. Every clause earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter escape hatch with no output schema, the description supplies the missing piece — the return shape { meta, response } — and covers the path construction rule. Nothing needed to call it correctly is 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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: the path must INCLUDE any query string, and it provides two concrete examples covering both a filtered collection and a single-resource lookup. That materially improves correct invocation.

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 precise verb+resource framing ('GET any Accelo API path') and immediately distinguishes itself from the dedicated get_/list_ siblings by scoping to paths 'not wrapped by a dedicated tool.' An agent can tell exactly what this does and when it differs from the 20+ specific 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?

It states the selection condition clearly ('any API path not wrapped by a dedicated tool'), which implicitly routes the agent toward the dedicated tools first. It stops short of an explicit when-not rule (e.g., 'prefer get_task over this for task reads'), so it is strong but not fully prescriptive.

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 labels this 'the highest-value safe write', but the annotations declare destructiveHint=true. Calling a tool whose annotation marks it destructive a 'safe write' gives the agent a contradicting safety signal, which is the exact failure mode the contradiction rule targets. The otherwise useful details (POST /api/v0/activities, form-encoded, returns { meta, response }) do not offset a direct conflict with the structured hint.

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?

Three short sentences, front-loaded with the mutation and its highest-value use case, then the required target fields, then transport/return details. Every clause earns its place, though the parenthetical '(required)' annotation on target fields is slightly redundant.

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 mutation tool with no output schema, it covers the key operational facts an agent needs: that it mutates data, the HTTP endpoint and encoding, and the shape of the response. The only real gap is the unresolved safety framing against the destructive annotation.

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 nine parameters are already documented in the schema; the description only restates that against_type + against_id identify the target and are required. That is a small value-add over the schema rather than meaningful new semantics, matching the baseline 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 states a specific verb (logs/creates) and resource (an activity: note, email, call, meeting) and explicitly names the target concept (against_type/against_id). It is immediately distinguishable from the get_/list_ activity siblings, which read rather than write.

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?

It gives concrete usage context — 'the highest-value safe write — e.g. add a note/comment to a job or company' — which tells the agent when this write is preferable among the create_* family. It stops short of naming explicit alternatives or when-not-to-use conditions, so it is clear but not fully routing.

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?

Annotations declare destructiveHint=true; the description reinforces this by saying it MUTATES Accelo data. It adds useful behavioral context beyond the annotation: form-encoded POST /api/v0/companies and returned shape { meta, response }, though auth/rate-limit/error behavior is not covered.

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?

Front-loads MUTATES and the core action, then adds endpoint, return shape, and update alternative in compact sentences. Every sentence adds contextual value without 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?

Covers the mutation, endpoint, encoding, return shape despite no output schema, and the update alternative, while the schema covers required fields. Missing auth/permission requirements and error handling keep it just short of fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters, including the nested fields object, are already documented in the schema. The description adds only body encoding detail (form-encoded) and no per-parameter semantics, fitting the baseline 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?

States a specific verb and resource: creates a new company/client organization. It also names the Accelo POST endpoint for company creation, clearly distinguishing it from get/list/update 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?

Clearly frames the tool as a mutation for new-company creation and notes that updates use POST /api/v0/companies/{id}, while no separate delete tool exists here. It does not explicitly name sibling tools for retrieval or generic requests, so it falls short of full when-to-use/when-not-to-use routing.

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 only destructiveHint=true in annotations, the description carries useful extra weight: it flags 'MUTATES Accelo data', specifies the wire format (form-encoded), and describes the return envelope { meta, response }. This is consistent with the annotation rather than contradicting it, though it omits side effects like whether duplicates are rejected or required auth scopes.

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?

Front-loads the mutation warning, then the endpoint, then the caveat, in four tight sentences with no filler. Every clause conveys something actionable.

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?

There is no output schema, and the description compensates by naming the return shape and the mutation semantics, so an agent knows what it gets back. It could go further on partial-failure or required-field behavior, but nothing essential for a correct call 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 description coverage is 100%, so every parameter is already documented at the schema level, which sets the baseline at 3. The description adds no per-parameter meaning beyond that, and the free-form 'fields' passthrough object is not explained any further in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('creates a new contact (a person)') and even names the concrete API surface (POST /api/v0/contacts). The parenthetical '(a person)' cleanly disambiguates it from the create_company sibling without needing the schema.

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 affiliation note is real usage guidance: it tells the agent that company linkage is NOT set here and must go through POST /api/v0/contacts/{id}/affiliations. That is a clear when-not plus a named alternative path. It stops short of explicitly contrasting with get_contact/list_contacts, so it is strong but not complete routing 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?

With destructiveHint=true already declared, the description still adds value: it discloses the exact endpoint (POST /api/v0/tasks), the form-encoded body convention, and the response envelope { meta, response }. It does not cover auth requirements or any post-write side effects, so not a 5.

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?

Three tight sentences, mutation warning and parent-object constraint front-loaded, with the API detail trailing. No filler and nothing repeated from the schema or annotations.

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 tool with no output schema, the description covers the mutation nature, the endpoint, the attachment requirement, and the return shape. Nothing an agent needs to invoke it correctly 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 100%, so 3 is the floor, but the description goes further by explaining the semantic rationale for against_type/against_id (a task is always attached to a parent object) and by noting that the 'fields' bag is merged into the form-encoded write body — meaning beyond the schema text.

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 gives a specific verb and resource ('MUTATES Accelo data: creates a new task') and immediately scopes it as a child-object creation ('always logged AGAINST an object'), which separates it from the flat entity creators like create_company or create_contact in the sibling 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?

It states a real usage prerequisite — that against_type and against_id are mandatory because tasks must attach to a parent object — but never says when to pick create_task over create_activity or the get_/list_task tools. Prerequisite coverage is good; alternative-selection guidance is absent.

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?

Annotations already declare readOnlyHint=true, so safety is covered; the description adds useful context beyond that by naming the underlying API call (GET /api/v0/activities/{id}) and the response envelope { meta, response }, which matters because no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the purpose, followed by the API mapping and return shape. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-record getter with annotations carrying the safety profile and full schema coverage, this is nearly complete, and the return envelope is a helpful addition given the absence of an output schema. Minor gaps remain around error behavior (e.g., not-found handling).

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 both the id and fields parameters are fully documented in the schema. The description adds no syntax or format detail beyond that, so the 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?

States a specific verb (Fetch) and resource (a single activity), and the parenthetical '(note/email/call/meeting)' clarifies what an activity actually is. The word 'single' implicitly contrasts with sibling list_activities, so an agent can route correctly.

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 is implied: fetch one record by id, as opposed to list_activities or create_activity. However, there is no explicit when-to-use/when-not guidance or named alternatives, so the agent must infer selection from the verb 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description does add useful context beyond the annotation: the underlying endpoint and the { meta, response } return envelope. It omits error behavior (e.g. unknown id) and pagination/field-expansion caveats.

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?

Three short sentences, front-loaded with the purpose before the endpoint detail and return shape. Nothing is wasted, though the raw API path is the least agent-relevant element.

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-resource getter with no output schema, stating the return envelope { meta, response } compensates reasonably for the missing output schema, and the endpoint confirms it is a plain read. Only error/empty-result behavior is unaddressed.

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 both 'id' and 'fields' are already documented in the schema. The description adds no parameter-level meaning (no id format, no note on when _ALL is expensive), so the 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?

States a specific verb and resource ('Fetch a single company') and the parenthetical '(client organization)' disambiguates the domain term. The word 'single' implicitly separates it from list_companies, but no sibling is named explicitly, which is the difference between a 4 and 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?

There is no when-to-use guidance: nothing says to use this for one known id versus list_companies for browsing, and nothing covers the 'fields' parameter as an optional expansion. Usage is only implied by the verb.

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?

readOnlyHint=true already declares this is a safe read, so the description's main addition is the underlying endpoint (GET /api/v0/contacts/{id}) and the { meta, response } envelope, which is genuinely useful since there is no output schema. It says nothing about error behavior (e.g. missing id) or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact fragments, front-loaded with the purpose before the endpoint and return shape. The endpoint line is mildly redundant for an agent but earns its place by anchoring the return envelope.

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 read tool with no output schema, the description covers purpose, endpoint, and response envelope, which is close to sufficient. Only the absence of any error/permission note keeps it from fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'id' and the '_fields' escape hatch are already documented in the schema. The description adds no syntax, format, or constraint detail beyond that, making the baseline 3 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?

States a specific verb ('Fetch') and resource ('a single contact (a person)'), with 'single' implicitly contrasting against the sibling list_contacts and create_contact. It never names an alternative explicitly, but the resource and cardinality 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?

No when-to-use guidance is given: nothing says to use this when you already have an id, nor that list_contacts is the alternative when you don't. The reader must infer the calling context entirely from the name and schema.

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?

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds useful context by mapping to the underlying Accelo endpoint (GET /api/v0/invoices/{id}) and hinting at the response envelope, but discloses nothing about auth needs, rate limits, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three terse sentences, front-loaded with the core action, followed by endpoint and return shape. No 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?

No output schema exists, but the description partially compensates by naming the return envelope { meta, response }. For a simple single-record fetch with full schema coverage and a readOnly annotation, this is nearly sufficient.

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 both 'id' and 'fields' are already documented in the schema. The description's {id} reference adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb+resource ('Fetch a single invoice') and the qualifier 'single' implicitly distinguishes it from list_invoices. It doesn't explicitly name the sibling, but the singular scope makes the distinction 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?

Usage is only implied by 'single invoice' versus the list_* siblings; there is no explicit when-to-use statement, no prerequisites, and no mention of the alternative list_invoices. Adequate but with clear gaps.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying API route and the top-level return envelope ({ meta, response }), which is modestly useful context, but it says nothing about error behavior when an id is missing or whether the response is paginated.

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?

Three short, front-loaded sentences with zero filler: purpose first, then endpoint, then return shape. Nothing redundant or buried.

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-record GET with no output schema, the description supplies the endpoint and the response envelope, which is close to sufficient. Only deeper error/edge-case behavior is absent, which is a minor gap for a read-only 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 100%, so both 'id' and 'fields' (including the '_ALL' option) are already documented in the schema. The description adds no format, example, or semantics beyond that, so the 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?

States a specific verb and resource ('Fetch a single issue') and clarifies the domain with '(support/service ticket)', which disambiguates from other record types like tasks or jobs. The word 'single' implicitly contrasts with list_issues, though it never names the sibling 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?

Usage is only implied: an agent can infer this is for retrieving one issue by id rather than listing many, but the description states no when-to-use condition, no prerequisites, and never names list_issues as the alternative.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the concrete endpoint and the top-level response envelope ({ meta, response }), but says nothing about not-found/error behavior or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three terse sentences, zero filler, with the resource and endpoint front-loaded before the return shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-by-id tool with full schema coverage and a readOnlyHint, this is nearly complete; the brief mention of the { meta, response } envelope compensates for the absent output schema. Only error-path context 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 100%, so both id and fields are fully documented in the schema itself. The description adds no syntax or semantic detail beyond that, which is the expected baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fetch a single job (project)') and pins the API operation (GET /api/v0/jobs/{id}). The word 'single' cleanly separates it from the sibling list_jobs.

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 is implied by the singular resource and the required id, but the description never states when to pick this over list_jobs or any other sibling, nor any prerequisite. Minimum-viable context only.

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?

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the underlying Accelo API endpoint and the response envelope shape, which is useful context, but says nothing about error behavior (e.g., unknown id) 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?

Three short, front-loaded sentences with no filler. The raw endpoint line is arguably redundant for an agent using the MCP tool, which keeps it just short of a 5.

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 by-id getter with no output schema, the description supplies the response envelope shape ({ meta, response }) and the backing endpoint, which is enough to call it correctly. Missing only error/edge-case 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?

Schema description coverage is 100%, so both the id and the _fields parameters are already documented in the schema. The description adds no format or syntax detail for _fields beyond what the schema provides, so the 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?

States a specific verb and resource ('Fetch a single prospect (sales opportunity)') and the parenthetical clarifies the domain term. The word 'single' implicitly separates it from list_prospects, but no sibling is named 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?

Usage is implied by the presence of a required id parameter and the 'single' qualifier, so an agent can infer this is the by-id lookup versus the list tool. However, there is no explicit when-to-use guidance or statement of prerequisites/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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying Accelo endpoint (GET /api/v0/staff/{id}) and the response envelope ({ meta, response }), which is useful context but not deep behavioral disclosure such as error handling or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences with no filler; the purpose leads and the endpoint/return details follow compactly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with no output schema, the description supplies the endpoint and the response envelope shape, which is enough for an agent to call it correctly. It could say more about error behavior, but the essentials are present.

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 both parameters (id, fields) are already documented in the schema. The description adds no parameter meaning beyond that, which matches the baseline of 3 when the schema does the heavy lifting.

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 ('Fetch') and resource ('a single staff member'), and the word 'single' implicitly contrasts with the sibling list_staff. It does not name the alternative explicitly, so it stops 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?

Usage is only implied by the word 'single' versus the list_staff sibling; there is no explicit when-to-use or when-not-to-use guidance, nor any mention of 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?

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the underlying API route (GET /api/v0/tasks/{id}) and a rough return envelope, which is useful, but says nothing about error behavior when the id is unknown or about the extra 'fields' cost.

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?

Three short fragments, front-loaded with the core action before the implementation detail and return shape. No filler, though the one-line purpose does overlap the title.

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?

There is no output schema, and the description compensates by naming the return envelope ({ meta, response }). For a trivial single-entity read whose safety profile is already in annotations, nothing essential 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 description coverage is 100%, with both 'id' and 'fields' documented in the schema itself, so the baseline is 3. The description's '{id}' reference confirms id is a path segment but adds no semantics beyond what the schema provides.

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?

Specific verb ('Fetch') plus specific resource ('a single task'), which distinguishes it from the sibling list_tasks without needing the schema. It does not explicitly name the sibling it contrasts with, so it stops 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?

The word 'single' implies this is for retrieving one known task id rather than enumerating tasks, so the usage is implied but never stated. No when-not-to-use guidance and no alternative tool (e.g., list_tasks) is 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?

readOnlyHint=true already declares the safe-read profile, so the description is not obligated to restate it. It adds value by disclosing the supported query modifiers (_page/_limit/_fields/_filters/_search) and the return envelope { meta, response }, but doesn't mention pagination defaults, rate limits, or max result windows.

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?

Three compact sentences: purpose, endpoint, modifiers, return shape. Front-loaded and waste-free, though the endpoint URL and return envelope are somewhat redundant with what the schema and agent context already convey.

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 read-only listing tool with fully documented parameters and no output schema, this covers purpose, endpoint, supported modifiers, and response shape. It stops short of stating pagination semantics or how meta relates to the response array, but the essentials are present.

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%, documenting each of the five parameters with types, defaults, and examples, so the schema does the heavy lifting. The description's shorthand list of the modifiers roughly mirrors the schema without adding syntax or constraints 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?

States a specific verb (List) and resource (activities), enumerates what an activity is (notes, emails, calls, meetings), and gives the concrete API endpoint. An agent can distinguish this from get_activity and create_activity immediately.

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?

Implies this is the bulk listing tool (and the singular get_activity sibling implies a single-record counterpart), but it never says when to use list_activities vs the generic accelo_request or when not to use it. No exclusions or alternative routing are 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds useful context beyond annotations: the underlying endpoint (GET /api/v0/companies) and the return envelope ({ meta, response }). It does not cover pagination behavior, rate limits, or auth needs.

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?

Three compact sentences, purpose front-loaded, with endpoint, supported params, and return shape following. 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 simple read-only list tool with fully documented parameters, the description covers purpose, endpoint, and return envelope, so no output schema is needed. Only deeper pagination/meta semantics are left unspecified, which 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?

Schema description coverage is 100%, so the schema already documents all five parameters in detail. The description only lists the parameter names (_page/_limit/_fields/_filters/_search) without adding syntax or semantics beyond what the schema provides, matching the baseline 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?

States a specific verb and resource ('List companies') and adds a clarifying gloss ('client organizations'), which helps disambiguate from staff/contacts. It is clearly distinct from get_company by the list vs. single-object framing, though it doesn't explicitly name the sibling it complements.

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 is implied by 'List' versus the sibling get_company for a single record, but there is no explicit statement of when to use this over get_company or other list_* tools, nor any prerequisites. Adequate but leaves routing to inference.

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?

readOnlyHint=true in annotations already establishes this as a safe read. The description adds useful context beyond that: the underlying API endpoint and the return envelope ({ meta, response }). It does not, however, describe pagination behavior, default ordering, or rate limits, so it goes modestly beyond 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?

Three terse sentences, front-loaded with what the tool is before the endpoint, supported params, and return shape. Every clause earns its place with no 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?

With no output schema, the description compensates by stating the return shape ({ meta, response }), and parameters are fully documented in the schema. It is nearly complete for a read-only list tool, though it omits discussion of pagination limits or total counts in the meta.

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 each parameter is already documented in detail with examples. The description only restates the parameter names (_page/_limit/_fields/_filters/_search) without adding syntax or format meaning, 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?

States a specific verb ('List') and resource ('contacts'), and parenthetically disambiguates the resource as 'people at companies', which separates it from list_companies. It also maps to the concrete Accelo endpoint. It does not explicitly name sibling tools, but the resource clarification is enough to distinguish it.

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 offers no when-to-use guidance or alternatives — it never says when to prefer list_contacts over get_contact, list_companies, or list_prospects, nor mentions prerequisites. It only enumerates supported query parameters, which is capability, not usage 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value by documenting the return envelope ('{ meta, response }'), which matters since there is no output schema, but it says nothing about pagination iteration, result-set size limits, or rate limiting.

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?

Three very short, front-loaded sentences with no filler; the core purpose leads and the technical details follow. The endpoint sentence ('Accelo API: GET /api/v0/invoices') is borderline redundant with the tool name but does document the upstream call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with fully documented parameters, the description covers purpose, underlying endpoint, available query modifiers, and the response envelope, which compensates for the absent output schema. Only the mechanics of iterating pages and any result limits are left unaddressed.

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 five parameters are already documented in detail in the schema. The description only restates the parameter names ('_page/_limit/_fields/_filters/_search') without adding semantics beyond what the schema provides, which is the baseline 3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource pair ('List invoices') and names the underlying endpoint, so the operation is unambiguous. It does not explicitly differentiate itself from the sibling get_invoice (single-record retrieval) or from the many other list_* tools, so an agent must infer the plural scope from the name alone.

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 when-to-use guidance, no condition selecting this over get_invoice, and no mention of prerequisites such as auth or required scopes. The supported query-parameter list hints at browsing/filtering, but that inference is left entirely to the reader.

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?

readOnlyHint=true already establishes the safety profile, so the description is not burdened with that. It usefully adds the pagination/filtering mechanism (via _page/_limit/_filters) and the return envelope '{ meta, response }', which matters because no output schema exists. It still omits rate limits or default page size nuance.

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 compact line: resource, endpoint, capability list, and return shape, with the core purpose front-loaded and no wasted phrasing.

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 5-param read-only list tool with fully documented schema, the description covers purpose, endpoint, filter mechanics, and the response envelope, compensating for the absent output schema. It stops short of usage routing or edge-case notes, but nothing critical 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 description coverage is 100%, so every parameter is fully documented in the schema itself; the description merely echoes the parameter names. Baseline of 3 is appropriate when the schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('List issues') and clarifies the resource domain as 'support/service tickets', plus the underlying API call GET /api/v0/issues. It does not differentiate itself from siblings such as get_issue or list_tasks, 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?

There is no guidance on when to use this versus get_issue or the other list_* siblings. The mention of supported query params is a capability statement, not a usage condition, leaving the agent to infer selection.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description earns credit beyond that by disclosing the underlying endpoint (GET /api/v0/jobs) and the response envelope { meta, response }, which the annotations do not convey.

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?

Three short sentences, zero filler, and the most disambiguating fact (jobs = projects) is front-loaded. Every clause carries information the agent needs.

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 usefully states the return envelope, and the schema fully covers inputs. What is missing is lighter than what is present: no note on empty-result behavior or whether the list is workspace-scoped.

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 the schema already documents all five parameters including pagination defaults and Accelo filter syntax. The description only restates the parameter names (_page/_limit/_fields/_filters/_search), adding no semantics beyond the schema — 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?

States a specific verb and resource ("List jobs") and immediately disambiguates the domain term: "Accelo 'jobs' are projects." An agent can confidently distinguish this from get_job or list_tasks without opening a schema.

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 is only implied by the name and the enumerated query features; there is no explicit when-to-use, no prerequisite, and no routing to siblings such as get_job (single record) or accelo_request (raw API). The listing of supported parameters nudges toward 'use this to enumerate jobs', but no alternatives or exclusions 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description goes beyond them by naming the concrete API endpoint and the return envelope ({ meta, response }), which is genuinely useful since no output schema exists. It stops short of describing pagination behavior 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?

Three short, front-loaded sentences with the core purpose first. The enumerated parameter list is largely redundant given the schema's 100% coverage, which is the only wasted content.

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 paginated read-only list tool with a fully described schema, the description supplies the endpoint and the { meta, response } return shape, which compensates for the missing output schema. Nothing essential for a correct call is missing, though pagination defaults are left to the 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?

Schema description coverage is 100%, so page/limit/fields/search/filters are already fully documented in the schema with examples and defaults. The description only re-lists the parameter names (_page/_limit/_fields/_filters/_search) without adding syntax or format detail, so the 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?

States a specific verb+resource and defines the resource semantically ('sales opportunities in the pipeline'), which is more than a restatement of the name. It does not, however, distinguish itself from sibling get_prospect (single) or explain how it relates to list_jobs/list_companies, so sibling differentiation 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?

The listing/plural framing implies 'use this to enumerate prospects', and the exposed filter/search params hint at retrieval use cases, but there is no explicit when-to-use, no when-not-to-use, and no reference to get_prospect for single-record lookups. Usage is inferable but not 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds modest value beyond that: the underlying HTTP endpoint and the { meta, response } envelope, which signals pagination metadata. It does not mention rate limits, auth requirements, or default result 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?

Three short sentences, front-loaded with what the tool is, then endpoint and query capability, then return shape. Efficient with no filler, though the 'Accelo API: GET ...' fragment is somewhat telegraphic.

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?

There is no output schema, but the description supplies the response envelope ({ meta, response }) and the endpoint, and the schema fully documents the five optional parameters. For a simple read-only list tool this is nearly complete; only sibling routing (list vs get) is left implicit.

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 five parameters are already fully documented in the schema, including the detailed _filters grammar. The description only echoes the parameter names, adding no meaning beyond the structured fields; 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?

States a specific verb+resource ('List staff') and usefully disambiguates staff as 'Accelo users in your deployment', plus names the backing endpoint GET /api/v0/staff. It does not explicitly contrast with the sibling get_staff, so an agent must infer list-vs-single, but the core 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?

No guidance on when to use this versus get_staff or accelo_request, and no prerequisites stated. The mention of supported query operators implies a listing/filtering use case but never states it, leaving usage to inference.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine context beyond that: the endpoint, the supported query mechanisms (_page/_limit/_fields/_filters/_search), that _filters is passed through verbatim, and the { meta, response } envelope.

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?

Three compact sentences with no filler, front-loaded with the purpose and then the mechanics. Slightly telegraphic but every clause carries 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?

With no output schema, the description compensates by naming the return envelope { meta, response }, and it covers the pagination/filter surface. It lacks guidance on filter syntax or error behavior, but for a read-only list tool it is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already fully documented in the schema, including format examples for _filters. The description merely names the same parameters, adding no syntax or semantics beyond the schema; 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?

States a specific verb+resource ("List tasks") and adds a clarifying gloss ("units of work logged against an object such as a job or company"), plus the backing endpoint GET /api/v0/tasks. It does not explicitly contrast with siblings like get_task or list_jobs, 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?

The verb "list" plus pagination/search parameters implies a browsing/collection use case, and a sibling get_task exists for single fetches, but the description never states when to use this rather than get_task or which filters are appropriate. Usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.