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

No annotations provided, so the description carries the full behavioral burden. It does not state permission requirements, whether the operation is idempotent, what happens if the manager already exists, or what the response looks like. This is a mutation tool with significant undisclosed 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 short but the Args section uses a code-documentation format that is not ideal for agent consumption. Each element is brief, but the structure could be more front-loaded with usage context.

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 annotations and no output schema, the description should provide more behavioral context (permissions, side effects, response). It covers parameters well but leaves critical behavioral gaps 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 coverage is 0%, so the description compensates by documenting all three parameters. It clarifies that manager_id is a 'staff_id' (useful disambiguation), that nature defaults to 'professional', and lists the enum values, which is not present in the schema. This adds meaningful 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?

States a specific verb (add) and resource relationship (staff member as manager of a company). It clearly distinguishes itself from siblings accelo_remove_company_manager and accelo_list_company_managers.

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?

Implied usage through the verb 'add' but no explicit when-to-use or when-not-to-use guidance, nor any mention of the sibling removal/list tools. Adequate but leaves context 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?

No annotations provided, so the description carries full behavioral burden. It says 'cancel and delete' but doesn't state whether the timer is recoverable after deletion, whether it requires the timer to be running, permissions needed, or what happens if the timer is already cancelled. For a destructive operation with no annotations, this is a significant gap.

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

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

Very concise with a clear first sentence stating the action. The Args section is redundant with the schema but harmless. Front-loaded and 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 destructive mutation tool with no annotations, no output schema, and 0% schema coverage, the description is thin. It should clarify the difference from accelo_delete_timer and whether cancel implies a soft-delete or state change versus hard deletion.

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 there is only one parameter ('id'). The description restates 'id: Timer ID' which adds minimal meaning beyond the parameter name itself. It doesn't clarify the ID format or whether it references a timer by numeric ID vs other identifier.

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 (cancel/delete) and resource (timer), distinguishing it from sibling accelo_delete_timer and accelo_pause_timer reasonably well. However, it doesn't clarify the distinction between cancel versus delete semantics, which matters given accelo_delete_timer exists as a sibling.

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 accelo_delete_timer, accelo_pause_timer, or accelo_start_timer. The agent must infer from the name alone that this is a combined cancel+delete operation.

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 behavioral burden and does disclose important side effects: auto-completing linked issues/tickets if configured and triggering invoicing. It does not cover permissions, reversibility, or rate limits, but the side-effect warning is substantial.

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 short and front-loaded: purpose first, then a high-value WARNING, then concise args. Every sentence earns its place without 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 mutation with no annotations, no output schema, and 0% schema description coverage, the description provides crucial side-effect context. It still omits reversibility, permissions, and a fuller explanation of the response, but it is largely complete enough to warn an agent about consequences.

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 explain parameters. It defines id as the Contract Period ID to close and fields as additional fields to return, but 'fields' remains vague about expected format and which fields are valid.

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: 'Close a contract period.' It clearly distinguishes this mutation from read-only siblings like accelo_get_contract_period and the opposite operation accelo_reopen_contract_period.

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 WARNING implies this tool should be used only when the agent intends to replicate a Web App period closure with its side effects. However, it does not explicitly say when to use this instead of accelo_reopen_contract_period or other alternatives, 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?

With no annotations, the description carries the full burden, and it does disclose a non-obvious behavior: two activities are created (a meeting plus a report on the meeting). It does not state what happens to the source time external (deleted, mutated, or left intact), whether the operation is idempotent or reversible, or what permissions are required — significant gaps for a mutation tool with zero annotation coverage.

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

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

The core purpose and the two-activity behavior are front-loaded in the first two sentences, with parameter detail relegated to a clearly labeled Args block. It is slightly verbose in restating 'against_type'/'against_id' alongside the parameter names, but every line 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?

For a three-parameter mutation tool with no annotations and no output schema, the description covers purpose, the surprising multi-record side effect, and all three parameters with domain context. It stops short of describing error conditions or the fate of the source record, which an agent would need for full confidence.

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, and it does: it maps each parameter to a domain meaning ('Time External ID', 'the against_type ... e.g. company, job, issue', 'the against_id — ID of the object to create against'). The example values for engagement_table are especially useful since the schema provides no enum or description for 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 first sentence names a specific verb and resource ('Convert a time external ... into an activity') and the second clarifies the exact side effect (a meeting activity plus a report activity). This clearly distinguishes it from generic siblings like accelo_create_activity or accelo_update_activity, which would otherwise look interchangeable.

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 implies context by describing the operation as 'the process for turning an imported appointment into a workable Accelo timesheet/schedule entry,' which suggests when it applies. However, it gives no explicit when-to-use guidance, no prerequisites (e.g. that the time external must first be found via accelo_list_time_externals), and no statement of when NOT to use it versus creating an activity directly.

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 does not disclose behavioral traits such as whether it's read-only, authentication requirements, rate limits, or return format (though no output schema exists, so return format is less critical). Minimal transparency.

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

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

One concise sentence with no waste. However, it's so terse that it lacks necessary detail, which is more of an under-specification issue than a conciseness flaw, but the sentence is efficient.

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 one required-free parameter and no annotations or output schema, the description should explain how to use the filters parameter and what it returns. It does neither, leaving significant gaps for correct 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 single parameter 'filters' has 0% schema description coverage – it's an untyped object with no explanation. The description says 'matching the given filters' but gives no detail on filter syntax, accepted fields, or structure. Fails to compensate for the coverage 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?

States a specific verb (count) and resource (activities) with a mention of filtering. Adequately distinguishes from sibling accelo_list_activities, though it doesn't explicitly name the alternative like the high-quality example 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 on when to use this tool versus accelo_list_activities or other count tools. The description gives no context or implied usage scenarios.

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 behavioral burden. It does not disclose that this is a read-only operation, what permission or rate limits apply, how filters are interpreted, or whether the count is exact or approximate.

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 definition is a single, front-loaded sentence with no wasted words. It is appropriately concise, though its brevity contributes to the overall lack of 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 count tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It omits filter structure, return behavior, and routing among sibling count/list tools.

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 single filters parameter is a generic object with no documented properties. The description merely says 'given filters' without adding any key names, value formats, or syntax beyond what the schema already lacks.

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 (Count) and resource (activity threads), making the tool's basic function clear. It does not explicitly differentiate itself from sibling tools like accelo_list_activity_threads or accelo_count_activities, but the count-versus-list distinction is inferable.

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 accelo_list_activity_threads or other counting siblings. The phrase 'matching the given filters' implies filtering but does not explain when counting is preferred over listing.

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 behavioral burden. It says nothing about whether the count respects user permissions, how filters are interpreted, or what happens when filters is null/omitted, which for a filter-driven query tool is a meaningful 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?

A single short sentence with zero waste and the core operation front-loaded. It is well sized, though its brevity is partly a result of under-specification rather than economy of 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 count tool with no annotations, no output schema, and an entirely undocumented free-form filter object, the description leaves the agent without enough to call it confidently. At minimum the filter format and the null-filters behavior should be stated.

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 single 'filters' parameter is a free-form object with additionalProperties true. The description says 'matching the given filters' but gives no filter syntax, supported keys, or default behavior when filters is null, so it does not compensate for the schema 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?

States a specific verb (Count) and resource (addresses), so the agent knows the operation at a glance. It does not explicitly distinguish itself from the sibling accelo_list_addresses, which returns records rather than a tally, so differentiation is left to the naming convention.

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 tells the agent to prefer this over accelo_list_addresses when only a total is needed, and no prerequisites or pagination caveats are mentioned. Only the tool name implies the intended use case.

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 doesn't disclose whether the operation is read-only (implied but unstated), what happens with invalid filters, rate limits, or what the return value looks like. For a count tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, front-loaded sentence that is efficient and contains no waste. However, it is arguably too terse given the missing parameter 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?

With no annotations, no output schema, 0% parameter description coverage, and a very terse description, the definition is completely inadequate. An agent cannot know what filters are valid, what the return value is, or how to correctly invoke the tool.

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

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

Schema description coverage is 0% and both parameters ('search' and 'filters') are undocumented in the schema. The description mentions 'filters' but provides no information about their format, allowed fields, or how 'search' interacts with 'filters'. The description fails to compensate for the complete lack of parameter documentation.

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 (count) and resource (affiliations) with the filtering scope, distinguishing it from siblings like accelo_list_affiliations and accelo_get_affiliation. It's clear but doesn't explicitly differentiate itself from the list sibling.

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 counting tool versus accelo_list_affiliations or how the count is scoped. The description only states the operation without context for selection among alternatives.

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 does not disclose whether counting requires any permissions, how filters are combined, whether counting is exact or approximate, or any performance/rate-limit behavior for a potentially expensive aggregation call.

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 efficient sentence with no waste. Front-loaded verb+resource. Brevity is appropriate, though it comes at the cost of the missing detail noted elsewhere.

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 2-param tool with 0% schema coverage, no annotations, and no output schema, the description is inadequate. An agent cannot know the filter shape, the units of the returned count, or when this tool is preferable to accelo_list_assets.

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 neither parameter has a title-level description. The description mentions 'filters' generically but adds nothing about the shape of the filters object or the search field, which is a free-text string. With two undocumented parameters, the description should have compensated and 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?

States a specific verb (count) and resource (assets) with scope (matching filters). Clear but provides no differentiation from siblings like accelo_list_assets or accelo_get_asset, which is the same gap shared by the ~50 other count_* 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 when-to-use guidance. The description does not say to use this instead of accelo_list_assets when only a total is needed, nor does it explain any prerequisites. An agent must infer the purpose entirely from 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?

No annotations are provided, so the description carries the full behavioral burden. "Count" implies a read-only operation, but the description does not state side-effect freedom, required permissions, rate limits, or any other behavioral traits.

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

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

A single front-loaded sentence with no wasted words. However, its extreme terseness leaves key semantics unaddressed, so it is concise but not maximally useful.

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 count tool, the description is minimally stated, but the filters parameter is completely undocumented and there are no annotations. It should at least clarify whether filters are optional or how they are structured.

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 only parameter, filters, is named but not explained; schema description coverage is 0%. The description does not add filter syntax, structure, or examples, so it fails to compensate for the schema gap.

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

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

States a specific verb and resource: "Count checklists" with filter scope. It distinguishes counting from listing implicitly, though it does not explicitly name the sibling accelo_list_checklists alternative.

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 "matching the given filters" implies the tool is for filtered counting, but it gives no explicit when-to-use guidance. It does not mention when to use this instead of accelo_list_checklists or other count siblings, nor any 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, so the description carries the full burden. 'Count' implies a read-only aggregate, but the description does not state behavioral traits such as whether it is read-only, whether it respects the same permission scoping as list_companies, or any rate-limit considerations.

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 short and front-loaded with the core purpose. The Args section is a bit raw/docstring-like but does add parameter context without excess verbosity.

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, no annotations, and 0% schema description coverage, the description leaves significant gaps: return shape (a count? a number?), error behavior, and permission model are 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 0% for both parameters, and the description partially compensates by stating the 'search' scope (website, name, phone, fax) and that 'filters' mirrors accelo_list_companies. However, it provides no format details for filters, and the search field semantics are only loosely clarified.

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 (Count) and resource (companies) with the scoping condition (matching the given filters). However, it does not distinguish itself from the sibling accelo_list_companies beyond the count-vs-list distinction, which is somewhat self-evident from the names.

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 explicit when-to-use or when-not-to-use guidance. It references accelo_list_companies for filter semantics, but does not say when a caller should prefer count over list (e.g., for aggregation or pagination-free totals).

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 does not state that this is a read-only, non-mutating operation, nor does it describe the return shape (a bare count vs. an envelope), rate limits, or what happens with no matching contacts.

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 efficient sentence with the resource front-loaded and no filler. It is appropriately sized but arguably too terse for a tool whose schema and annotations are entirely empty.

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 zero annotation coverage, 0% schema description coverage, and no output schema, the description should carry much more. It omits what 'search' does, what the count response looks like, and when this is preferable to listing contacts, leaving material gaps for an 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 coverage is 0%, so the schema documents neither parameter. The description references 'filters' but says nothing about the separate 'search' parameter, its syntax, or how search differs from filters, leaving half the parameters effectively undocumented.

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 (Count) and resource (contacts) plus the filtering scope, so the operation is unambiguous. However, it does not differentiate itself from the many sibling count tools or from accelo_list_contacts, so an agent must still infer which count family member to pick.

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 count tool versus accelo_list_contacts or the other accelo_count_* siblings. There is no mention of required permissions, prerequisites, or conditions that select this over a list-and-count 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?

No annotations are provided, so the description carries the full burden but adds no behavioral context beyond the basic purpose. It does not disclose whether the count is approximate, how large result sets are handled, whether the operation requires specific permissions, or any other operational traits.

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 core action. It is concise but perhaps too terse, missing opportunities to clarify usage or 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?

With no annotations, no output schema, and 0% parameter coverage, the description is insufficient for an agent to confidently invoke the tool. It lacks details on parameters, behavior, and when to use it, making it incomplete for a tool with potential filtering 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 description coverage is 0%, so the description must compensate for the undocumented parameters 'search' and 'filters'. It only vaguely references 'given filters' without explaining what the parameters accept, their formats, or examples, leaving significant gaps.

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 ('Count') and resource ('contracts'), clearly distinguishing it from sibling tools like accelo_list_contracts and accelo_get_contract. It doesn't explicitly name those siblings, 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 description provides no guidance on when to use this tool versus alternatives (e.g., accelo_list_contracts for retrieving full records). Usage is only implied by the tool's name and description, with no explicit when-to-use conditions.

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 states that counting happens but says nothing about permissions, rate limits, whether the count respects pagination, or what the return shape is. For a query tool with zero annotation coverage this is a significant gap.

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

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

A single short sentence that is front-loaded and free of filler. It is appropriately sized for a simple count operation, though its brevity comes at the cost of the missing detail noted elsewhere.

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 undocumented parameters, no schema descriptions, no annotations, and no output schema, the description is far too thin. An agent cannot determine what a contributor is, how to construct filters, or what the result looks like, so the definition is not sufficient to call 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?

Schema description coverage is 0%, so the description must compensate. The parameters 'search' and 'filters' are mentioned only as 'filters' in prose, and there is no explanation of the syntax, format, or accepted keys for either the search string or the filters object. The description does not add usable meaning beyond the bare parameter names.

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 (count) and resource (contributors), which is clearer than a bare name restatement. However it does not distinguish itself from the sibling accelo_list_contributors beyond the count/list distinction, leaving the agent to infer the difference. Vague about what a 'contributor' is in this domain.

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 count tool versus accelo_list_contributors or accelo_count_contributor_types. The agent must infer that this returns a count rather than a list, and there is no mention of alternatives or exclusion conditions.

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. It does not state that the operation is read-only, whether it requires specific permissions, rate limits, or what the return payload contains. Only the minimal 'Count' semantics are implied.

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 words. It delivers the core operation without any redundant or meandering 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?

With no output schema, no annotations, and a schema that only defines an untyped `filters` object, the description is too thin. It does not explain the return format, filter capabilities, or behavioral guarantees needed to invoke the tool confidently.

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 only parameter `filters` is left as a generic object with no field documentation. The description mentions 'filters' but adds no meaning about accepted filter keys, value formats, or default behavior.

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 ('Count') and resource ('contributor types') with a scope modifier ('matching the given filters'). It does not, however, differentiate itself from the sibling tool `accelo_list_contributor_types`, which an agent would need to distinguish count vs. list semantics.

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 like `accelo_list_contributor_types` or `accelo_get_contributor_type`. There are no prerequisites, exclusions, or context cues beyond the bare description.

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 behavioral burden. It confirms the tool counts rather than lists, but says nothing about whether it is read-only, what permission scope it requires, or how the optional filters argument behaves when omitted.

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 short sentence with no filler, front-loading the verb and resource. It is appropriately sized for a simple tool, though it could have used its small budget to document the filters argument.

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 minimal one-parameter count tool with no output schema and no annotations, the description is barely adequate. It conveys the core operation, but the opaque filters parameter and the presence of accelo_list_divisions mean an agent lacks enough context to invoke it confidently.

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% for the single "filters" parameter, which is an unspecified free-form object. The description references "the given filters" but adds no field names, syntax, or examples, so it fails to compensate for the schema gap.

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

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

The description states a specific verb ("Count") and resource ("divisions"), making the operation unambiguous. It does not distinguish itself from the sibling accelo_list_divisions or explain why one would count rather than 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 phrase "matching the given filters" hints at context but gives no when-to-use guidance, no mention of when to prefer accelo_list_divisions, and no prerequisites or exclusions. The agent must infer usage entirely.

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 behavioral burden. It discloses that invalid endpoint combinations return a structured error and that search is only supported "where supported," which is useful. However, it does not describe return format (no output schema), authentication needs, or other behavioral traits.

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

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

The description is front-loaded with the core action, followed by critical constraints and a structured Args list. Every sentence adds information without 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?

Given four parameters with 0% schema coverage, no annotations, and no output schema, the description does reasonably well but leaves gaps: it doesn't explain what a successful response contains, error structure details, or any rate limiting. It is minimally adequate but not comprehensive.

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% across four parameters, so the schema provides no parameter documentation. The description adds meaning by giving examples for object ("issues") and enum_type ("statuses"), clarifying that filters is a "Filter dict," and that search applies to titles where supported. This is valuable but partially incomplete for a 0% coverage 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 gives a specific verb ("Count") and resource ("an object's enumeration values") and includes the filtering constraint. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling accelo_list_enum beyond the count vs list distinction.

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 key usage constraint: only some enumerations expose a count endpoint, and directs the agent to accelo_list_enum for valid pairs. This is actionable routing guidance, though it doesn't cover all when-to-use scenarios.

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 behavioral burden. It does not state that this is a read-only/safe operation, what it returns (a numeric count), or any permission or rate-limit 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?

A single front-loaded sentence with no filler or redundancy. It is appropriately sized for a simple count tool, though extremely sparse relative to the undocumented 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?

For a tool with two entirely undocumented parameters, no annotations, and no output schema, the description leaves the agent without the information needed to construct a correct call. It neither explains the filter shape nor the return value.

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% for both 'search' and 'filters'. The description alludes to filters generically but never explains the difference between the search string and the filter object, or what filter keys are accepted.

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 (Count) and resource (expenses) with the scoping condition 'matching the given filters'. This distinguishes it from sibling accelo_list_expenses, though the description never names that alternative 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 phrase 'matching the given filters' implies filtered counting but gives no when-to-use guidance, no mention of accelo_list_expenses as the alternative for retrieving records, and no exclusion criteria.

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 behavioral burden, and it discloses almost nothing beyond the implicit read-only nature of a count. It does not describe permissions, whether the count respects the caller's visibility scope, or the shape of the result (a number vs. an object).

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 grammatical sentence with zero waste and the operation front-loaded. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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 an open-ended filters object, no annotations, no output schema, and zero parameter documentation, the description is insufficient. An agent still cannot tell what filter keys are valid, what 'search' does, or what the return value looks like.

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

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

Schema description coverage is 0%, with two undocumented parameters ('search' and an open-ended 'filters' object with additionalProperties). The description references 'filters' only as a vague phrase and says nothing about the 'search' parameter or the accepted filter keys, so it fails to compensate for the coverage 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 states a specific verb+resource ('Count groups') and a scope ('matching the given filters'), so an agent knows exactly what operation is performed. However, it does not distinguish itself from the sibling accelo_list_groups or the many other accelo_count_* tools, leaving sibling differentiation to 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 guidance on when to use count versus list, nor any statement of prerequisites or context. The phrase 'matching the given filters' implies filtering applies but never says which filters or when counting is preferable to listing.

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 behavioral burden, yet it discloses nothing about read-only nature, response shape (a count integer), or rate limits. 'Matching the given filters' hints at filtering behavior but is far too thin for a tool with zero annotation coverage.

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

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

A single short sentence with no wasted words; the purpose is front-loaded. It is concise, though there is very little content overall to 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?

For a 2-parameter tool with 0% schema coverage, no annotations, and no output schema, the description is too sparse — it does not compensate for the missing parameter documentation or explain the count semantics the agent needs.

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 two parameters ('search', 'filters') are essentially undocumented both in schema and description. The vague reference to 'given filters' does not explain what keys the filters object accepts or how 'search' differs from 'filters'.

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 clear verb ('Count') and resource ('holidays'), and the 'matching the given filters' phrase distinguishes it slightly from the sibling accelo_list_holidays. However it does not name that sibling or explain the distinction explicitly, so it sits at the minimum-viable level.

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 about when to use this count endpoint versus accelo_list_holidays, no note that results are unfiltered by default, and no mention of how 'filters' interacts with 'search'. The agent is left to infer usage entirely.

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, yet it says nothing about what is returned (a numeric count), whether nested interactions are included, permissions, or rate limits. The 'single activity' scope is the only behavioral detail offered.

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 single sentence with a clean args block and no wasted words. Appropriately sized for a one-parameter count tool, though the args section restates the obvious.

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, so the description should explain what the count represents or its return shape, but it does not. For a tool whose entire value is a numeric result, that is a meaningful omission.

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 schema only labels the property 'Id', so the description's 'id: Activity ID' does add needed meaning. However it provides no format, type, or example guidance beyond identifying the parameter as an activity identifier.

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 (count) and resource (interactions) and scopes it to a single activity, which distinguishes it from sibling list/count tools like accelo_list_interactions and accelo_count_activities. It is clear on its own but does not explicitly name the alternatives it competes with.

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 prerequisites, and no comparison to the numerous sibling count/list tools. The agent must infer the use case entirely from the tool name and the one-line purpose.

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 the Beta status but says nothing about return format, pagination (irrelevant for count), required permissions, or how the filter object is structured. For a count operation with zero annotation coverage, this is thin.

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 short sentence that is front-loaded with the verb and resource. No wasted words, though the 'Beta' suffix adds little for an agent.

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 zero schema coverage, no annotations, and no output schema, the description is too sparse. It doesn't explain the filter parameter format or what the count result represents, leaving significant gaps for an agent to call 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?

Schema description coverage is 0% and there are 2 parameters (search, filters). The description doesn't explain what 'search' covers or the expected format/keys of the 'filters' object. Since the schema has no property descriptions, the description needed to compensate but did 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?

Statement of a specific verb (Count) and resource (invoice line items) with the filtering scope. It clearly distinguishes itself from the sibling list tool accelo_list_invoice_line_items, though it does not name it 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 word 'Count' implies usage for getting totals rather than listing items, which is a natural distinction from accelo_list_invoice_line_items. However, there is no explicit when-to-use guidance, no mention of when not to use it, and the 'Beta' tag is unexplained.

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 behavioral burden. It implies a read-only count but does not state permissions, whether deleted invoices are included, rate limits, or any other operational trait beyond the basic action.

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

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

A single front-loaded sentence with no wasted words. It is appropriately sized for a simple count tool, though its brevity contributes to missing parameter and behavioral 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?

With no annotations, no output schema, and 0% schema description coverage, the description is too thin for an agent to invoke this tool confidently. Filter and search semantics remain unspecified, so an agent must guess how to construct valid calls.

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% for two parameters. The description only repeats 'filters' and never explains the 'search' parameter, filter syntax, allowed filter keys, or matching behavior, so it adds no real meaning 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?

States a clear verb and resource: counting invoices matching filters. It distinguishes count from list by the verb itself, though it does not explicitly name or differentiate from siblings like accelo_list_invoices.

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?

Provides no when-to-use guidance, no prerequisites, and no comparison to alternatives such as accelo_list_invoices or accelo_count_invoice_line_items. The phrase 'matching the given filters' gives no selection 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 carries the full burden. It does not confirm this is a read-only operation, does not describe what the filters object accepts, and says nothing about return shape or permission/scope behavior for counting issues.

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 front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is also the source of the other gaps.

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 annotations, no output schema, and fully undocumented parameters, one sentence is not enough. The agent has no information about filter syntax, search semantics, or what the count result represents.

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% with two parameters ('search' and 'filters'), yet the description only echoes 'filters' and never mentions 'search' or the expected structure of either argument. Since the schema documents nothing, the description should compensate and 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?

States a specific verb ('Count') and resource ('issues'), which cleanly separates it from accelo_list_issues and accelo_get_issue. It does not explicitly name the sibling or state the count-vs-fetch distinction, 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?

'matching the given filters' implies a filtered count but gives no when-to-use guidance, no note about when to prefer accelo_list_issues instead, and no prerequisites. An agent must infer the distinction from the name alone.

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

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 says nothing about return format (e.g., an integer), permissions required, rate limits, or how filters are applied, leaving the agent with almost no 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?

A single, front-loaded sentence with zero wasted words. It is appropriately sized for the minimal information it conveys.

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 count tool with no annotations, no output schema, and zero schema descriptions, the description should at least clarify what filters and search accept and confirm the return type. It does neither, so an agent lacks sufficient context to invoke it confidently.

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% for both parameters. The description only mentions 'filters' in passing and completely omits the 'search' parameter, adding no meaning beyond the property names and leaving both parameters effectively undocumented.

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 (Count) and resource (jobs) with a scope (matching the given filters). It is clear what the tool does, but it does not explicitly differentiate itself from siblings like accelo_list_jobs or name alternatives.

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?

Only implies that the tool is for counting jobs that match filters. There is no guidance on when to use it versus accelo_list_jobs or other count tools, and no prerequisites or exclusions are mentioned.

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

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

With no annotations, the description carries the full behavioral burden, yet it discloses nothing beyond the verb. It does not state that this is a read-only/non-mutating operation, whether filters are required or optional, or what happens when no filters are supplied.

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 front-loaded sentence with zero waste. Its brevity is appropriate in form, though it is under-specified rather than 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?

For a tool with no annotations, no output schema, and 0% parameter documentation, the description leaves the filter contract and the read-only nature undisclosed. It is not sufficient for an agent to call it correctly with confidence.

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 schema documents nothing. The description mentions 'filters' but never explains the 'search' parameter or the expected shape/keys of the filters object, leaving both parameters effectively opaque.

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 ('Count') and resource ('ledgers'), making it distinguishable from accelo_list_ledgers and accelo_get_ledger by the counting semantics. However, it does not explicitly reference those siblings to confirm the distinction, 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 phrase 'matching the given filters' hints at a narrowed query, but there is no guidance on when to use this versus accelo_list_ledgers, nor any prerequisite or exclusion. The agent must infer usage entirely.

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 does not say what is returned (a scalar count?), whether the filters object is free-form or schema-constrained, or how 'search' behaves. For a tool with zero structured behavioral coverage this is a significant gap.

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

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

A single efficient sentence with the verb and scope front-loaded and no filler. It is concise, though arguably at the cost of needed 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 two-parameter tool with no annotations, no output schema, and an untyped free-form filters object, the description leaves too much unexplained. An agent cannot determine filter syntax or the return type from this definition.

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 vaguely references 'the given filters' but never explains the filters object shape, the additionalProperties:true contract, or what the 'search' parameter matches against.

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 (count) and resource (milestones), which is clearer than the tautological siblings. However it does nothing to differentiate from accelo_list_milestones or accelo_get_milestone, leaving the agent to infer that this returns a number rather than records.

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 mention of the list/get alternatives, and no indication of when counting is preferable to listing. Usage is only implied by the verb 'count'.

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. It doesn't disclose pagination behavior, whether the count respects filters or ignores them, return format, or any rate limits. For a count tool with no annotations, this is a significant gap.

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

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

A single, efficient sentence that is front-loaded with the verb and resource. No wasted words. However, it may be too terse given the ambiguity around filter semantics.

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, no annotations, and a free-form filters parameter. The description doesn't explain what the count represents, how filters work, or what the return might look like. For a tool with these structured gaps, the 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 0% and there's only one parameter ('filters') which accepts an arbitrary object. The description mentions 'given filters' but provides no filter syntax, available fields, or examples. With low coverage and a free-form object parameter, the description should compensate but does not.

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

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

Clear verb ('Count') and resource ('object budgets') with a stated scope ('matching the given filters'). It sits among many 'count_*' siblings, and the resource name distinguishes it, but there's no explicit differentiation from accelo_list_object_budgets or accelo_get_object_budget beyond the count semantics.

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, when-not-to-use, or alternative tool guidance is given. The phrase 'matching the given filters' implies usage but doesn't explain when a count is preferable to a list or how filters should be formed.

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 says nothing about permissions, rate limits, what 'filters' accepts, or what the count returns (an integer? an object?). For a tool whose behavior is entirely undisclosed, this is a significant gap.

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

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

One short sentence, front-loaded and free of waste. It is appropriately sized, though it borders on under-specification rather than true 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 tool with zero annotations, no output schema, and a completely undocumented free-form parameter, the description is incomplete. An agent cannot determine what filters to pass or what the return value looks like.

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

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

Schema description coverage is 0% and the single parameter 'filters' is typed only as a free-form object with no description. The description ('matching the given filters') adds nothing about the shape, keys, or accepted values of the filters object, leaving the parameter completely undocumented.

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 a specific verb (Count) and resource (payments) with a scoping constraint (matching the given filters). It matches the naming pattern of many sibling count_* tools but doesn't explicitly differentiate itself from accelo_list_payments or accelo_get_payment.

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 verb 'Count' – an agent can infer this is for getting a total rather than a list. However, the description doesn't state when to prefer this over accelo_list_payments or how it relates to other count tools, leaving the choice 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?

With no annotations, the description carries the full disclosure burden. It says nothing about permissions required, whether the count respects search vs filters precedence, or what the response shape is (a count value). For a read-only query tool this leaves 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?

A single tight sentence with the operation front-loaded and no filler. It is efficient, though its brevity borders on under-specification rather than optimal 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 two-parameter tool with no annotations and no output schema, the definition should at minimum explain filter format (possibly pointing at accelo_list_filters) and confirm the return is a numeric count. Neither is present, leaving the definition incomplete for correct 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?

Schema description coverage is 0%, so the description must compensate, but it only vaguely references "filters" and says nothing about the `search` parameter or the expected structure/keys of the free-form `filters` object (additionalProperties: true). The agent has no way to know valid filter syntax from the definition alone.

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 ("Count") and resource ("prospects") with the scoping condition ("matching the given filters"), which is enough to distinguish it from the list/get/create/update/delete prospect siblings. It does not, however, explicitly name list_prospects as the alternative for retrieving records rather than totals.

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 counting versus list_prospects, nor any mention of prerequisites, pagination, or cost/rate considerations. The phrase "matching the given filters" hints at filtering but leaves the agent to infer usage conditions.

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 behavioral burden, yet it discloses nothing beyond the verb. It does not state that this is a read-only/side-effect-free operation, what happens when filters are omitted, or how results are returned.

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 short sentence with no filler and the purpose front-loaded. It is efficiently sized, though the brevity stems partly from under-specification rather than genuine economy.

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% parameter documentation, the description should do far more work. An agent lacks the filter format, the meaning of 'search', and any behavioral context needed to invoke it confidently.

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 both parameters ('search' and 'filters') are undocumented in the schema. The description mentions 'filters' generically but never explains the 'search' parameter or the accepted filter syntax, so it fails to compensate for the coverage 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?

States a specific verb ('count') and resource ('purchases'), so the core intent is unambiguous. However it does not distinguish itself from siblings like accelo_list_purchases or accelo_get_purchase, leaving the count-vs-list distinction to inference.

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 counting versus listing or getting purchases, nor any mention of required permissions or prerequisites. Usage is only implied by the tool name.

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 doesn't state the return shape, whether filters are translated to a query, pagination, empty-result behavior, or auth needs. 'Count matching the given filters' is the bare minimum.

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 efficient sentence, front-loaded and free of waste. Concise but perhaps too terse given the 0% schema coverage.

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?

2 parameters, 0% schema coverage, no annotations, no output schema. A count tool's whole value proposition rests on the filter semantics, which are entirely undisclosed. The definition is incomplete for how a caller would actually use it.

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 names neither parameter's semantics. 'search' and 'filters' are undocumented in schema and description, leaving the agent to guess the filter syntax and what search does. The description adds nothing beyond the bare existence of filtering.

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 'count' and resource 'quotes', clearly distinguishing it from accelo_list_quotes and accelo_get_quote among many siblings. It doesn't repeat the name redundantly or leave purpose ambiguous.

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 statement of when to use this versus accelo_list_quotes or accelo_get_quote. With an enormous sibling list including accelo_list_quotes and accelo_count_activities, guidance on selecting count over list would be valuable and 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?

No annotations are provided, so the description carries the full burden. It implies a read-only aggregation but does not mention permissions, rate limits, whether the count is scoped or filtered, or the return type. Behavioral context is minimal.

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

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

A single short sentence that is front-loaded and contains no filler. Every word contributes to stating the action and its scope.

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 zero-param count tool, the description is adequate to invoke the tool, but with no annotations and no output schema it leaves the return format, safety profile, and any deployment-scoping caveats unstated. It is minimally viable but not rich.

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 tool takes zero parameters, so there is no parameter semantics to explain. The empty schema is fully consistent with the description, and the baseline for zero params is a 4.

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 ('Count') and resource ('rates'), plus scope ('on the deployment'). This is clear enough to distinguish from list_rates or get_rate by the verb itself, but the description does not explicitly name or contrast with those siblings.

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 indication of when to prefer this over accelo_list_rates or accelo_get_rate, and no prerequisites or context. The purpose is implied only by the word 'Count'.

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 behavioral burden, yet it says nothing about the return type (an integer count), whether it is read-only/safe, pagination irrelevance, or error behavior. Only the bare action is 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?

A single front-loaded sentence with no filler, which is proportionate for a simple count tool. It is efficient, though borderline terse given the undocumented parameter.

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 annotations, no output schema, and 0% parameter documentation, the description omits return format, filter structure, and safety profile. An agent knows what it does but not how to call it precisely or what it gets back.

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%, so the description must explain the lone 'filters' parameter, but it only references it generically with no hint of accepted keys, value types, or shape for a free-form object. It adds essentially nothing beyond the schema's parameter name.

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 (count) and resource (referrals), which cleanly distinguishes it from accelo_list_referrals and accelo_get_referral. It does not explicitly name those siblings, but the count-vs-list distinction is inherent in the verb.

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 instead of accelo_list_referrals or accelo_get_referral, nor any note on why an agent would want a count rather than the records themselves. 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say what the count covers, whether multiple filters are ANDed, how search interacts with filters, or what the form of the returned count is. 'Matching the given filters' is the only behavioral 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?

One short, front-loaded sentence with no filler or repetition. It is efficient, though the terseness borders on under-specification rather than ideal brevity.

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 undocumented parameters, no annotations, and no output schema, the description is far too thin. An agent cannot determine filter syntax, the effect of search, or what the returned count represents from this definition alone.

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 there are two parameters, so the description must compensate. It mentions 'filters' generically but says nothing about the 'search' parameter or any filter key/format syntax, leaving the agent with no more information than the parameter names already give.

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 ('Count') plus resource ('requests') and scopes it to filters, which cleanly distinguishes it from accelo_list_requests and accelo_get_request. It does not explicitly differentiate itself from the other count_* siblings, but the resource noun carries that job.

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 count versus when to call accelo_list_requests, no mention of whether filters are required, and no note that a bare call returns a total. The agent must infer usage entirely from the name.

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 disclosure burden. Beyond implying a read, it says nothing about behavior on large result sets, what the filter object accepts, or what the count response represents.

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 well-formed sentence with the resource disambiguation front and center. No filler, though it is arguably under-specified rather than merely 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 annotations, no output schema, and 0% parameter coverage, the description leaves key gaps: the shape of the filters object, the role of 'search', and what the returned count covers. Too little for a tool whose structured fields explain almost nothing.

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 neither parameter is documented in the schema. The description references 'the given filters' but adds no semantics for the free-form filters object, and the 'search' parameter is never mentioned.

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 (Count) and resource, and usefully disambiguates that 'resources' means attachments, which an agent could not infer from the name alone. It doesn't explicitly differentiate from the sibling accelo_list_resources, but the count-vs-list distinction is self-evident from the verb.

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 a count instead of accelo_list_resources, nor any prerequisite or context. The usage (need a tally, not the records) is only weakly 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only count, but discloses nothing about the filter format, whether unfiltered calls return a global count, or what the response contains. For a tool with zero annotation coverage this is thin.

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, front-loaded sentence with no filler, which satisfies conciseness. However, given the undocumented filter parameter, brevity here reads as under-specification rather than efficient editing.

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 a fully undocumented free-form filters object, the description omits everything an agent would need to invoke this correctly beyond the tool's general intent.

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 single 'filters' parameter is an unconstrained anyOf object/null. The description only restates the parameter name ('matching the given filters') without adding accepted keys, format, or constraints, so it does not compensate for the coverage 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?

Clear verb (count) plus resource (segmentations), which distinguishes it from the sibling list_segmentations, get_segmentation and other count_* tools by its counting semantics. It does not, however, explicitly differentiate itself from accelo_list_segmentations or explain the distinction between a count and a 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 gives no when-to-use guidance, no indication that this is preferable to list_segmentations when only the total is needed, and no prerequisites. 'Matching the given filters' implies filtering but never states which filters exist or whether they are optional.

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 behavioral burden. It implies a read-only count operation, but does not disclose permissions, rate limits, whether it counts only accessible records, or how results are returned.

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 with no wasted words, and the core action is front-loaded. However, it is under-specified rather than optimally structured for a tool with two optional 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?

For a count tool with no annotations, no output schema, and 0% schema coverage, the description is too sparse. It does not explain the difference between search and filters, what filters accept, or what the count represents.

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 explain the parameters. It mentions 'filters' only vaguely and completely omits the 'search' parameter, adding no meaningful semantics beyond the parameter names.

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 ('Count') and resource ('signoffs'), making the core action clear. It does not distinguish this tool from sibling list/count tools like accelo_list_signoffs, but the purpose is still understandable.

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 given about when to use this count tool instead of accelo_list_signoffs or other signoff-related tools. The phrase 'matching the given filters' implies filtering, but there are no explicit usage conditions or alternatives.

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 burden. It does not disclose that this is a read-only, non-destructive operation, nor what the count response looks like (integer? wrapped object?), nor any permission 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?

A single front-loaded sentence with no wasted words, but the brevity reflects under-specification rather than efficient communication.

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 annotations, no output schema, and two completely undocumented parameters, the description leaves the agent without enough to call it correctly. It needs at least filter semantics and response shape.

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?

With 0% schema description coverage across two parameters, the description must compensate but does not. It vaguely references 'filters' without explaining accepted keys or syntax, and never mentions the 'search' parameter at all.

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 ('Count skills'), which is a distinct operation from the sibling accelo_list_skills. It is clear and unambiguous, but it does not explicitly contrast itself with the list/count sibling set.

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 prefer counting over listing, or any mention of the obvious alternative accelo_list_skills. The trigger context is left entirely to inference from the tool name.

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

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 doesn't disclose what 'filters' supports, whether the count is exact or approximate, whether it requires specific permissions, or what the response contains beyond a number (no output schema). Minimal transparency for a query 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?

A single, front-loaded sentence that is efficient and contains no redundant or filler content. Appropriate length given the limited information provided.

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 filterable count tool with one entirely undocumented parameter, no annotations, and no output schema, the description leaves large gaps. It doesn't define filter syntax, result semantics, or usage context relative to sibling list tools, so an agent cannot fully rely on it without external knowledge.

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% – the single 'filters' parameter is an untyped arbitrary object with no documented properties. The description merely restates 'matching the given filters' without adding syntax, allowed fields, or format details, leaving the parameter essentially opaque.

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 (count) and resource (staff members), which is clear enough. However, the phrase 'matching the given filters' adds no scope beyond what the name implies, and there are no siblings with overlapping intent among accelo_list_staff or accelo_get_staff to require differentiation.

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 count tool versus accelo_list_staff or accelo_get_staff. With no exclusions or alternatives mentioned, the agent must infer usage from the name alone.

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

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, and it says nothing about permissions, rate limits, pagination, or the shape of the count result. The only behavioral hint is that results are scoped by filters, which is already implied by the schema.

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 single sentence is front-loaded and free of filler, which is appropriate in form. The problem is under-specification rather than verbosity: there is simply not enough content to guide invocation.

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% parameter documentation, the description is the only source of behavioral and parameter information, and it supplies almost none. An agent would have to guess at filter syntax and whether 'search' is a text query.

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% for two parameters, so the description must compensate and does not. It gestures at 'filters' but never explains the filter object's structure, accepted keys, or the purpose of the separate 'search' 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 names a specific verb and resource ('Count tags'), so an agent immediately knows the operation and the object. However, it does not differentiate itself from the sibling accelo_list_tags or explain how a count differs operationally from a list (e.g., returns only a number).

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 mention of the alternative accelo_list_tags, and no statement about whether filters are required or what happens when they are omitted. 'Matching the given filters' restates the existence of a parameter rather than telling the agent when this tool is the right choice.

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 behavioral burden. It does not disclose read-only nature, whether filters are ANDed, what happens with an empty/null filter, or any auth or rate-limit behavior. For a tool with zero annotation coverage, this is a meaningful 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?

A single efficient sentence with the action front-loaded and no filler. It is well-sized, though its brevity reflects under-specification rather than disciplined trimming.

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, no annotations, and two entirely undocumented parameters, the definition leaves too much unspecified for an agent to invoke it confidently. At minimum it should explain the filter format and what the count represents.

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 both 'search' and 'filters' are undocumented in the schema. The description mentions 'filters' only in passing and says nothing about the search parameter, the filters object shape, or accepted keys, so it fails to compensate for the coverage 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?

States a specific verb ('Count') and resource ('tasks'), and the word 'matching' implies filtering. It is clearly distinguishable from accelo_list_tasks or accelo_get_task by the counting semantics, but it never explicitly contrasts itself with those siblings.

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 count versus list, whether filters are required or optional, or what context this tool fits into. The agent must infer everything from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Count' implies a read-only aggregate, but the description says nothing about the return value, filter semantics, permissions, or whether the count respects pagination or defaults.

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 front-loaded sentence with no filler; it is appropriately short for a simple counting tool, though the brevity is achieved partly by omitting necessary 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?

With 0% parameter coverage, no annotations, no output schema, and a free-form filter object, the description leaves an agent unable to construct a correct call or know what the result looks like. It should at least sketch the filter shape and confirm the numeric return.

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 one parameter ('filters') with 0% schema description coverage, and the schema itself is an opaque object with additionalProperties=true. The phrase 'the given filters' adds no syntax, key names, or format detail to compensate for the coverage 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 states a specific verb ('count') and resource ('tax codes') and matches its name, distinguishing it from siblings like accelo_list_taxes and accelo_get_tax. It does not, however, explicitly contrast itself with those siblings in the 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 only usage signal is 'matching the given filters' — there is no statement of when a count is preferable to accelo_list_taxes, no mention of prerequisites, and no exclusions. An agent must infer the use case 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: not that it is read-only, not the return shape, and not how 'the given filters' are applied. 'Matching the given filters' hints at scoping but stops short of real 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?

A single economical sentence with no padding, front-loaded on the verb. It is terse to the point of under-specification, but structurally clean.

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 two-parameter counting tool with 0% schema coverage, no output schema and no annotations, the description is too thin. It neither defines the domain concept nor the filter format the agent must supply.

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% for both 'search' and 'filters', so the schema contributes nothing and the description must compensate. It only says filtering exists and never explains the expected filter keys or what 'search' matches.

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 ('Count') and resource ('time externals'), so an agent can distinguish it from the list/get/convert siblings. However, it offers no explicit differentiation text and leaves the term 'time externals' unexplained.

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 and no mention of alternatives such as accelo_list_time_externals (for full records) or accelo_get_time_external. The agent must infer that this returns only a count.

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 states the medium default ('note') and marks three required fields, but says nothing about permissions needed, visibility of the created activity, side effects, or what happens with an invalid against_type. For a mutation tool with zero annotation coverage this is a real 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 one-line purpose is front-loaded and the Args list is compact, one line per parameter. A few lines (priority_id, class_id, owner_id) restate their names without adding value, which is minor waste but not 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?

For a 12-parameter mutation tool with no annotations and no output schema, the description covers parameters adequately but leaves behavioral context thin: no auth/permission requirements, no note on what the created activity returns or its side effects. It is complete on the argument surface but incomplete on 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?

With 0% schema description coverage, the description is the only documentation, and it documents all 12 parameters. It adds genuine meaning for several: against_type examples (company, job, issue, staff, task), owner_type options ('staff' or 'affiliation'), medium enum values and default, and the unit for billable/nonbillable ('seconds'). A few entries are tautological (priority_id: Priority ID, class_id: Activity class ID), which keeps it from a 5.

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 ('Create a new activity') and enumerates the subtypes it covers (note, email, call, meeting), which helps distinguish it from siblings like accelo_create_task or accelo_create_expense. It does not explicitly contrast itself with accelo_update_activity or accelo_convert_time_external_to_activity, so it stops short of full sibling differentiation.

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 or when-not-to-use guidance. There is no statement about choosing this over accelo_create_task/accelo_create_issue, nor about prerequisites such as needing a valid against_type/against_id before calling. The medium default hints at usage but that is schema-level detail, not 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?

No annotations are provided, so the description bears full burden. It does not disclose side effects, required permissions, whether the address is immediately available, or error conditions. Only states it creates an address, with no behavioral 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 well-structured with a header and bullet-like param list. It's front-loaded with the core action 'Create a new address.' and then details. Not overly verbose, but could be slightly more concise by omitting redundant labels like 'Street1: First line of street address' given the name is self-explanatory.

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 14-parameter mutation tool with no annotations and no output schema, the description provides necessary parameter info but lacks behavioral context, such as return values, error handling, or permissions. It's minimally adequate but leaves gaps an agent might need.

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 so by listing all 14 parameters with brief explanations (e.g., 'state: State/province name (use if state_id unknown)'), clarifying required vs optional and mutual exclusivity between name and ID fields. This is strong compensation, though some parameters like 'fields' are vaguely explained ('Additional fields to return').

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 specific verb and resource: 'Create a new address.' This directly distinguishes it from siblings like accelo_update_address and accelo_list_addresses. Missing explicit sibling differentiation, but 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?

No guidance on when to use this tool versus alternatives or in what context. It doesn't mention prerequisites (e.g., needing an existing company or contact) or exclusions. The agent must infer usage entirely.

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 behavioral burden. It never says what permissions are needed, what happens if the contact is already affiliated with the company (duplicate handling), or what the call returns. For a write operation this is a significant gap.

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

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

Compact and front-loaded: the purpose is the first sentence, and the argument list is easy to scan. Slight redundancy in repeating each parameter name alongside its gloss, but nothing wasteful enough to hurt.

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 annotations and no output schema, the parameter coverage is adequate, but the description says nothing about mutation-side behavior (duplicate handling, permissions, idempotency) or return shape. It is minimally complete for invocation but thin on the write semantics an agent needs.

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, and it does list all seven parameters with a short gloss for each, including explicit (required) markers on company_id and contact_id. The glosses for email/phone/mobile largely restate the names, but the required/optional split and the framing add real value.

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 (Create) and resource (affiliation) and adds a clarifying gloss — 'link a contact to a company' — that makes the domain concept unambiguous. It is clearly distinct from siblings like update_affiliation or delete_affiliation, though it never names them.

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 or when-not-to-use guidance, no mention of alternatives (e.g. use update_affiliation for existing links), and no prerequisites beyond which args are required. The agent must infer all of this from the name alone.

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

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

With no annotations, the description carries full burden. It usefully constrains linked_object_type to the supported values (issue, job, prospect, contract), but says nothing about permission requirements, idempotency, duplicate-link handling, or the response for this mutation.

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 front-loaded summary sentence followed by a compact Args list. Every line adds information 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 no-annotation mutation tool with no output schema, the description covers inputs well but omits behavior an agent needs: permissions, failure/conflict semantics, and whether a link can be duplicated or must be unique.

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 — and it does, documenting all six parameters, marking the three required ones, giving the unix-timestamp format for start_date/end_date, and enumerating valid linked_object_type values.

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 ('Create') and resource ('asset link'), and names both endpoints (an asset and another object). It is readily distinguishable from sibling read/delete operations like accelo_list_asset_links and accelo_delete_asset_link, though it never explicitly names them.

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 offered and no alternatives are referenced; the sibling accelo_delete_asset_link and accelo_list_asset_links are not mentioned. The agent must infer usage entirely from the name.

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 behavioral burden. It discloses the useful constraint that against_type currently only supports 'task', but says nothing about permissions required, side effects, whether the created checklist is returned, or error behavior 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?

Front-loaded purpose sentence followed by a compact args list; every line maps to a parameter. No wasted prose, though the 'Args:' format is functional rather than polished.

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 annotations, no output schema, and 0% schema coverage, the description covers the inputs well but is silent on permissions, side effects, and downstream behavior. Since no output schema exists, it could reasonably note what the call yields, leaving it 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?

With 0% schema description coverage, the description must compensate, and it largely does: it documents all four parameters, marks the three required ones, explains the accepted value for against_type, and gives a concrete example item shape ({'title':'...','ordering':0}). Only 'fields' is left unexplained, keeping it out of the 5 range.

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 ('Create a new checklist'), which cleanly distinguishes it from the sibling update/delete/list checklist tools. It's clear but doesn't explicitly call out those siblings, so it stops short of the top band.

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 reach for this tool versus alternatives, nor any prerequisites or exclusions beyond the parameter-level note that only 'task' is supported for against_type. That note is a constraint, not usage 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses that this is a create operation and notes one parameter interaction ('standing' overridden by 'status_id'), but omits permissions, duplicate behavior, side effects, and return format 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 front-loaded with the core action and then provides a compact, well-structured argument list. Given the absence of schema descriptions, every line in the Args block adds useful information without 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 10-parameter create tool with no annotations, no output schema, and 0% schema description coverage, the description covers purpose and parameter semantics reasonably well. However, it lacks usage guidance, behavioral details, and any indication of what the call returns, leaving meaningful 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?

With schema description coverage at 0%, the description compensates by listing all 10 parameters with human-readable meanings. It marks 'name' as required and clarifies the override relationship between 'standing' and 'status_id', though it lacks expected formats or value domains for fields like 'status_id' and 'standing'.

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: 'Create a new company in Accelo.' This clearly distinguishes it from sibling tools such as accelo_get_company, accelo_list_companies, accelo_update_company, and accelo_delete_company.

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 no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as permissions or duplicate handling. The create intent is implied by the verb, but no usage context is provided.

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, and it does disclose one important behavioral trait: the automatic affiliation creation. Beyond that it is silent on permissions, whether an existing affiliation is duplicated, and failure behavior for an invalid company_id.

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 one-sentence summary is front-loaded and carries the key side effect; the Args block is terse and each line adds a distinct semantic. Some repetition of parameter names is unavoidable given the schema has no descriptions.

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 nine-parameter mutation tool with no annotations and no output schema, the definition covers inputs and the affiliation side effect adequately, but says nothing about what is returned (the new contact ID) or how errors/invalid company_id are handled.

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, and it largely does: it glosses all nine parameters and clarifies the ambiguous 'title' as an honorific (Mr, Ms) versus 'position' as the job title. Only 'fields' stays opaque ('Additional fields to return').

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+resource ('Create a new contact') and adds a meaningful qualifier: the call also creates an affiliation to the company. That side effect distinguishes it from accelo_create_affiliation and tells the agent it does not need a second call, though 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?

There is no when-to-use or when-not guidance. The agent gets no instruction on when to prefer this over accelo_create_affiliation plus a separate contact creation, or what preconditions (e.g. an existing company_id) must hold.

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 behavioral burden. It only says 'Create a new expense' and does not disclose permission requirements, whether the mutation is idempotent/reversible, rate limits, or what happens to related objects. With 10 parameters and no annotations, the behavioral picture is largely absent.

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 front-loaded with the core action and then a parameter list, which is reasonable structure. But 'Args:' formatting is a docstring artifact rather than a well-structured description, and several entries are redundant with the schema. It is not bloated, but it also is not tightly authored for an agent.

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 10-parameter mutation tool with no annotations and no output schema, the description leaves major context gaps: valid values for against_type, the meaning/format of fields, whether billable/reimbursable are typed as strings for yes/no, and what the API returns. It provides required-field markers but not enough for an agent to confidently construct a valid call.

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, and it does list each parameter with a short gloss and required flag. However, several glosses are pure restatements ('title: Expense title', 'type_id: Expense type ID') and crucial semantic details are missing: against_type's valid values, fields' expected format, and date_incurred's unix timestamp is noted but not the timezone/units. The list adds marginal meaning beyond the schema but does not fully compensate for 0% 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 starts with a specific verb+resource: 'Create a new expense.' That is clear and distinguishes it from accelo_update_expense, accelo_list_expenses, and accelo_delete_expense by name/verb. It does not, however, explicitly differentiate from siblings or describe what an 'expense' means in this domain (e.g. against a job or activity), 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?

No 'when to use' or 'when not to use' guidance is provided. It gives required-field markers but never explains the context in which an expense should be created (e.g. against a job, purchase, or activity) or how it relates to siblings like accelo_create_activity or accelo_create_purchase. There is no exclusion 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 behavioral burden. 'Create' implies a mutation, but the description never states permission requirements, what the response returns, or whether duplicate/overlapping holidays are allowed. The '(Beta)' note and mutual-exclusivity rule are the only behavioral signals.

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?

Purpose and the mutual-exclusivity constraint are front-loaded, and the Args list is compact. Minor redundancy in restating parameter names, but each line adds a format or default not present in the schema.

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 annotations are absent, so a complete description should cover at least the mutation's return shape and permission expectations. It fully covers inputs and one key constraint but leaves the post-call behavior unspecified for a write 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%, so the Args block does real work: it documents all six parameters including formats ('unix timestamp'), default behavior ('staff_id defaults to current user'), and the mutual-exclusivity of date_end vs duration_seconds. It meaningfully compensates for the undocumented 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?

States a specific verb+resource ('Create a new holiday') that clearly separates it from the get/list/update/delete holiday siblings. The '(Beta)' tag adds mild status context but the definition doesn't explicitly position it against alternatives.

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 no when-to-use guidance, prerequisites, or conditions under which a caller would create a holiday rather than update one. Only the param-level mutual exclusivity of date_end/duration_seconds is offered as a constraint, which is not usage 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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing beyond 'create' — no side effects (notifications, status defaults), no permission requirements, and no indication of what the against_type/against_id linkage does. For an unannotated mutation tool 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 front-loaded with the core action and the required fields are marked, with no filler sentences. The raw 'Args:' block is functional though slightly mechanical, and required vs optional is only conveyed by the '(required)' tag on some entries.

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 and no output schema, the description covers the 13 parameters adequately but omits behavioral context: validation requirements, side effects, and what the call returns. It is minimally complete for a mutation tool but leaves an agent guessing about the write semantics.

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's inline arg list is the only source of parameter meaning. It adds useful semantics beyond bare titles: against_type 'e.g. company, job', assignee as 'Staff ID to assign', date fields as 'unix timestamp', and 'fields: Additional fields to return'. A few IDs (type_id, class_id, status_id, priority_id) remain unexplained, but overall it compensates well for the schema 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 opens with a specific verb+resource: 'Create a new issue (ticket).' This cleanly distinguishes it from the update/delete/list/get issue siblings. It does not explicitly reference any sibling, but the create verb and parenthetical clarify the resource unambiguously.

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, when-not-to-use, or alternative guidance is given. The description never mentions prerequisites (e.g. that a valid type_id or against_type/against_id must already exist), nor does it route the agent to accelo_update_issue or accelo_create_task.

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 behavioral burden. It does not say whether the call requires specific permissions, what the response contains, whether required IDs must pre-exist, or what happens if an optional field is omitted. The only added behavioral hint is 'Initial status ID', which implies a status transition at creation.

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 purpose sentence is good and the arg list is scannable, but each Args line largely restates the schema property name plus title (e.g. 'date_due: Due date'), adding length without much new 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 10-parameter mutation tool with no annotations and no output schema, the description is thin: it omits valid values for the against_type/type_id/status_id foreign keys, says nothing about the created object or its return shape, and gives no error or permission context. An agent could construct the call but would likely guess at enum-like string values.

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, and it does partially: it flags unix timestamps for date_due/date_started, clarifies that against_type/against_id are an object type/ID pair, and that manager_id is a staff ID. However, it never enumerates valid against_type values (company, prospect, contact, etc.) or explains the 'fields' return-projection, leaving key semantics unresolved.

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 ('Create a new job (project)'), which an agent can distinguish from the sibling read/update/delete job tools. It stops short of explicitly differentiating itself from accelo_list_jobs or accelo_update_job, but the verb 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 when-to-use guidance, no prerequisites, and no mention of alternatives such as accelo_create_task or accelo_create_issue for work that isn't a job. The agent must infer that this is the entry point for job creation purely from the name.

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 the mutation ('Create') and lists parameters, but omits permissions, side effects, idempotency, error behavior, and rate limits. This is a significant gap for a create operation.

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

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

The description is front-loaded with a clear purpose sentence and then a structured Args block that efficiently documents every parameter. There is no wasteful repetition, though the list format is somewhat schema-like rather than narrative.

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 no annotations, no output schema, and 0% schema description coverage, the description adequately covers parameter semantics and implies the return value ('fields: Additional fields to return on the created material'). However, it lacks essential behavioral context such as authentication needs, error handling, and side effects that an agent would need 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?

Schema description coverage is 0%, so the description must compensate for all six parameters. It documents each parameter with meaning: budget_id (ID of object budget), title (material title/description), quantity, unit_cost (cost per unit), billable ('yes' or 'no'), and fields (additional fields to return). This is thorough, though it lacks constraints like numeric ranges or validation rules.

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 ('Create') and resource ('new material line item on an object budget'), clearly distinguishing it from sibling operations like update or list. An agent can immediately tell what the tool does without opening 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 description only states what the tool does, with no guidance on when to use it versus alternatives like accelo_update_object_budget_material or accelo_list_object_budget_materials. No prerequisites, when-not conditions, or routing hints are provided.

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 behavioral burden, yet it says nothing about permissions, whether the call is destructive/irreversible, what the response contains (new ID?), or duplicate-handling. For a mutation tool with zero annotation coverage this is a real 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?

Purpose is front-loaded in one clear sentence, followed by a structured arg list. The Args block mirrors the schema somewhat, but each line earns its place by supplying semantics the schema omits.

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 9-parameter mutation tool with no annotations and no output schema, the description documents inputs adequately but is silent on return value, side effects and prerequisite data. Minimum viable but with 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: it marks the three required fields and adds units/format detail the schema lacks, such as 'unix timestamp' for date_due and the '0-5' range for weighting. It falls short of explaining what 'fields' or 'status_id' values are acceptable.

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 ('Create a new prospect') and clarifies the domain entity with '(sale)'. Sibling tools like accelo_list_prospects, accelo_get_prospect and accelo_update_prospect make the CRUD role inferable, but the description never explicitly differentiates itself from those siblings.

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 statement of when to use this versus alternatives, and no prerequisites beyond the required-parameter list. An agent is not told, for example, that an affiliation and prospect type must already exist, or when to prefer creating a prospect over a job or request.

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 implies a write operation but says nothing about authentication requirements, permission scope, whether the created quote is a draft or published, or what the response contains. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

The lead sentence is front-loaded and the parameter list is compact one-liners. The generated 'Args:' block is somewhat boilerplate but every line earns its place by supplying missing parameter semantics.

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 11 parameters, a mutation side effect, no output schema, and no annotations, the definition covers inputs well but omits return shape, side effects, and usage context. It is adequate for invocation but not for an agent reasoning about consequences.

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 annotates all 11 parameters with meaning: requireds are flagged, 'against_type' is given the concrete example 'prospect', 'date_expiry' is noted as a unix timestamp, and three fields are identified as HTML. This substantially fills the schema gap, though types and nullability are not fully restated.

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 ('Create a new quote (proposal)'), which distinguishes it from accelo_update_quote, accelo_get_quote, accelo_list_quotes, and accelo_count_quotes in the sibling set. The parenthetical synonym 'proposal' adds useful domain disambiguation.

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 statement of when to use this tool versus accelo_update_quote or other siblings, and no workflow context (e.g., a quote typically attaches to a prospect or job). The agent is left to infer the creation use case from the name alone.

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