CentralStationCRM MCP by usefulapi

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds that the operation is a count and that results can optionally be constrained by tag, but it does not cover authentication, rate limits, or whether the count respects any other filters.

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 meaning is front-loaded in a single clear sentence, followed by a short endpoint reference. There is no redundant or filler text.

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

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

For a simple two-parameter count tool with full schema coverage and safety annotations, the description is largely complete. It states the return concept ('Total number') even without an output schema, though it could clarify how counts relate to search/list alternatives.

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

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

Schema description coverage is 100%, and the schema already defines the resource enum values and the tag_name filter. The description repeats both parameters at a high level without adding syntax or format details beyond what the schema provides.

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

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

The description states a specific verb and resource: it returns the total number of people, companies, deals, or projects, with an optional tag filter. This clearly distinguishes it from list/search siblings that return record collections rather than counts.

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 'Total number' and the optional tag filter, but the description never states when to use this instead of list_* or search_* tools. No alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the description's added value is the side-effect note "Nothing is sent to the contact" (no notification fired on the person/contact) plus the underlying endpoint. It does not address duplicate-name behavior or what is returned, which matters given idempotentHint=false.

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

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

Three telegraphic fragments, front-loaded with the WRITE marker and the core action, with zero padding. "POST /companies" is the least load-bearing part but is short enough not to hurt readability.

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

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

The schema fully documents the three inputs and annotations carry the safety profile, so the essentials are covered. However, with no output schema, the description never says what comes back (created id, object shape), which an agent needs after a non-idempotent create.

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

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

Schema description coverage is 100% — name, user_id (default: the API user) and background are all documented with limits in the schema. The description contributes nothing about parameters, so the baseline 3 is the correct ceiling.

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?

"WRITE: create a company" gives a specific verb plus resource, and the resource noun (company) distinguishes it from create_person, create_deal, create_task and the other create siblings. It stops short of naming an alternative or the boundary with update_company, but the intended action 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?

There is no when-to-use guidance, no precondition (e.g. whether to check for an existing company via search_companies first), and no named alternative. The WRITE prefix implies a mutation but nothing tells the agent how to choose this over the sibling create/update tools.

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

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

Annotations already declare non-destructive, open-world, non-idempotent write behavior, so the description adds real value on top: 'the vendor says what is missing' discloses server-side validation error behavior, and 'Nothing is sent to the contact' rules out an email/notification side effect the agent might otherwise worry about. Success return shape is unstated.

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?

Four short sentences, front-loaded with the WRITE marker and operation, then prerequisite lookup, then conditional requirements, then the side-effect caveat. Nothing is 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 an 11-parameter write tool with no output schema, the description covers lookup prerequisites, conditional requirements, validation behavior, and side effects. It omits any statement about what a successful call returns (e.g., the created deal id), which an agent would want with no output schema available.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds a cross-parameter dependency the schema cannot express: pipelines with a monetary value or target date require value and target_date. The value_type default note merely restates 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?

Opens with a specific verb and resource ('WRITE: create a deal (sales opportunity)') plus the endpoint POST /deals, which cleanly separates it from get_deal, update_deal, and list_deals in the sibling set. An agent can identify the operation 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?

Explicitly routes the agent to list_deal_types for pipeline and stage ids, and states a conditional prerequisite (value and target_date required when the pipeline has a monetary value or target date). No explicit when-not-to-use guidance against update_deal, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the "WRITE:" prefix is consistent with that rather than contradicting it. The description adds genuinely non-obvious behavioral context the annotations cannot carry: the note lands in entity history and produces no outbound communication to the contact, which is exactly the risk question an agent would have before calling a write 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?

Three short fragments, zero filler, with the WRITE classification and the core action front-loaded before the side-effect clarification. Every sentence earns its place.

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

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

With annotations covering the safety profile and full schema coverage of all seven parameters, the description supplies the missing conceptual layer: multi-entity attachment and the absence of contact notification. The one real gap is that the schema requires only name and content while the description says "one or more" targets, leaving the agent unsure whether an untargeted note is valid or orphaned.

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

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

Schema description coverage is 100%, so name, content, the four *_ids arrays and confidential are all documented in the schema, making the baseline 3 appropriate. The description's "one or more people, companies, deals or projects" adds a little framing by grouping the four ID arrays, but gives no guidance on whether at least one target is required, and the schema marks none of them required.

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+resource ("add a note") plus the attachment scope ("history of one or more people, companies, deals or projects"), which clearly separates it from read-side siblings like get_note and list_notes. It stops short of naming an alternative explicitly, but the WRITE-prefixed phrasing leaves no real ambiguity.

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?

"Nothing is sent to the contact" is a useful exclusion that tells the agent this is not a messaging/email action, implying a different tool is needed for actual outreach, and "POST /protocols" anchors the mechanism. However, no sibling is named and there is no explicit statement of when to prefer this over create_task or an update tool, so usage is only implied.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds genuinely useful context beyond that: 'Nothing is sent to the contact', which reassures the agent no email/SMS side effect occurs, plus the POST endpoint. It does not mention the duplicate-creation risk implied by idempotentHint=false, so not a 5.

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

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

Two terse sentences, front-loaded with the 'WRITE:' classification, and zero filler. Every clause earns its place.

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

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

For a 9-parameter create tool with no output schema, the description covers the required field, optional related data, and side-effect context. It stops short of indicating what is returned (e.g. the new person's id), which the agent would need for follow-up calls, so it is good but not fully complete.

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

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

Schema coverage is 78% and the schema documents every parameter including nested email/phone structure, limits, and the quirky country_code-as-language field. The description only restates the last-name requirement and optional emails/phones, adding little beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb ('create') and resource ('contact person'), calls out the required field (last name), and names the optional related data. It is clearly distinguishable from the sibling create_company/create_deal/create_task 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?

Usage is implied by 'create a contact person', but there is no explicit statement of when to use this versus update_person (for existing contacts) or the create_* siblings. An agent must infer the choice from the verb alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: it is a write operation, it hits POST /tasks, and crucially that no outbound communication reaches the contact. It does not discuss whether re-creating produces duplicates, which the non-idempotent hint implies.

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

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

Two tight sentences with the operation and its scope front-loaded, and no redundant restatement of the name or title. Every clause (task kinds, optional attachment, assignment, no-contact-send, endpoint) carries distinct information.

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

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

With 7 parameters, two enums, no nested objects, and full schema coverage, the description plus annotations give an agent enough to call the tool correctly. The one gap is the return value: with no output schema, the agent is not told whether the created task (and its id) is returned, which matters for chaining into update_task. Otherwise complete.

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

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

Schema description coverage is 100%, so every parameter is already documented in detail, including defaults and the attachable_id/attachable_type pairing. The description reinforces that attachment is optional and names the type options, but adds no syntax, format, or default information beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb (create) and resource (task), enumerates the task kinds (to-do, call, email, visit), and clarifies the optional attachment/assignment dimensions. It is clearly distinguishable from sibling creators like create_note or create_deal, and the 'Nothing is sent to the contact' clause separates it from any messaging action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent knows this is the tool for making a task, but there is no explicit guidance on when to prefer it over update_task, create_note, or list_calendar_events. The 'Nothing is sent to the contact' note is a useful scoping hint but is not a when/when-not routing rule.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real value beyond them by disclosing that related records can be embedded in the same call, and the schema note reinforces that no extra call is needed for them.

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

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

Two short sentences, front-loaded with the core behavior and followed by the optional expansion. Nothing is wasted.

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

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

With no output schema, the description is expected to convey the return shape, and 'one company by id' plus the optional embedded records does that adequately. It could say more about error behavior for a nonexistent id, but nothing critical is missing 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 100%, so both parameters are already documented, establishing a baseline of 3. The description's enumeration of related record types adds some orientation but diverges from the enum (it says 'people' and 'contact details' where the schema has 'connections', 'tels', 'emails', 'homepages', and omits 'positions' and 'projects').

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 with scope: 'one company by id', which implicitly separates it from the list_/search_ company siblings by operating on a single identified record. It does not name those siblings explicitly, 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?

Usage is implied: fetch a single company when you have its id, and add includes to avoid extra calls. There is no explicit statement of when to prefer this over list_companies or search_companies, nor of prerequisites around obtaining the id.

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

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

Annotations already establish this as a safe read-only operation, and the description adds useful context: the result is keyed to the API key, includes account/subdomain and timezone, and is retrieved via GET /user. It does not describe failure behavior or nullability, but that is a minor gap given the annotations.

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

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

The description is front-loaded, compact, and every piece contributes: identity scope, returned fields, the practical use of the id, and the endpoint. There is no wasted text.

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

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

With no input parameters, no output schema, and read-only annotations, the description is complete enough for an agent to call the tool correctly. It enumerates the returned fields and explains the key use of the user id.

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 has zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 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?

The description states a specific resource and scope: the CentralStationCRM user tied to the current API key. It clearly distinguishes this from sibling user-related tools such as list_users by specifying 'this API key belongs to.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context by explaining that the returned user id should be used to assign records or tasks. It does not explicitly contrast this tool with list_users or other alternatives, but the 'current API key' scope makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that related records can be embedded in the same call and gives the underlying GET endpoint, but does not cover error behavior, permissions, or response shape. This is useful context beyond annotations, though modest.

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

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

Two compact sentences with no wasted wording. The primary behavior is front-loaded, followed by the optional expansion and endpoint reference.

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

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

For a simple read-only get-by-id tool with complete schema coverage and annotations, the description is nearly sufficient. It tells the agent what is returned and how includes work. Minor gaps around error cases or pagination are not central for this lookup.

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

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

Schema description coverage is 100%, and both deal_id and includes are documented in the schema, including the note that embedding avoids an extra call. The description echoes the includes fields but adds no syntax or formatting details beyond the schema. Baseline 3 is appropriate when the schema carries the parameter semantics.

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

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

States a specific retrieval action and resource: one deal by id. The optional includes are named, so the agent knows the scope. It does not explicitly contrast with list_deals or search_deals, but the single-id framing makes the distinction reasonably clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'by id' and the optional includes, but there is no explicit guidance on when to use this versus list_deals, search_deals, or get_deal_stats. An agent can infer the direct-lookup case, but no alternatives or exclusions are stated.

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

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false) and world scope, so the bar is lower. The description still adds genuine value by disclosing the returned metrics (count, total value) and that values are expressed in the account currency — information not available anywhere else since there is no output 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?

Two tight sentences with the core output description front-loaded. The trailing 'GET /deals/stats' is low-value for an agent that never makes HTTP calls directly, but it is brief rather than bloated.

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-required-parameter read tool with annotations and no output schema, the description supplies what is actually needed: what is measured, the currency semantics, and the optional filter. Only minor gaps remain, such as whether stats aggregate across pipelines or time periods.

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 100% schema coverage the single parameter is already documented, so the baseline is 3. The description earns an extra point by stating the parameter is optional and defining the no-argument default (all deals), which the schema alone does not convey.

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 resource and output (number and total value of deals) plus an optional scope (tag-filtered), which cleanly separates it from list_deals/search_deals. It stops short of naming a sibling explicitly, so an agent must infer the boundary itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Number and total value of all deals' implies an aggregate-count use case, and the parenthetical clarifies when to pass a tag. However, there is no explicit guidance on when to pick this over list_deals or count_records, and no exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety behavior is covered. The description adds one genuinely useful piece of context by mapping 'note' to the API's 'protocols' resource (GET /protocols/{id}), but says nothing about error behavior for missing ids.

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

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

Two short fragments, zero waste, and the identifying scope ('by id') is front-loaded. Slightly cryptic in that the raw endpoint is dropped in without explanation, but nothing is redundant.

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

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

For a single-parameter read tool with full schema coverage and complete annotations, this is adequate but thin. With no output schema, a brief note on what a returned note contains (or what happens for an unknown id) would close the remaining gap.

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

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

Schema coverage is 100% and the note_id parameter is fully documented as the CentralStationCRM protocol (note) id. The description adds no syntax, type, or format detail beyond the schema, so the baseline 3 applies.

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

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

States a clear resource (a single note / history entry) and the scoping key (by id), which distinguishes it from the sibling centralstationcrm_list_notes. It doesn't explicitly say 'retrieve', but 'Get note' plus the path make the action unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'by id' suggests use when you already have an id, versus list_notes or search_all when you don't. No explicit when-to-use or when-not-to-use statement, and no sibling is named.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context that 'includes' avoids extra calls, but says nothing about not-found behavior, permission requirements, or response shape.

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

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

Two compact sentences, front-loaded with the core operation and closed with the endpoint. Every clause earns its place and there is no filler.

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

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

For a simple two-parameter read tool with no output schema and full schema coverage plus safety annotations, the description is essentially sufficient. It only lacks an error/absence note, which is minor at this complexity.

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

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

Schema coverage is 100%, so both parameters are documented in the schema itself, including the full enum of includes values. The description lists a subset of related-record types (companies, deals, tags, tasks, emails, phones, addresses) but omits positions, projects and homepages, adding little 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 (get), resource (person), retrieval key (id), and the endpoint GET /people/{id}. It implicitly contrasts with list_people and search_people via 'One person by id', though it never names those siblings 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?

Implied usage is clear: use it to fetch a single person when you have an id. There is no explicit guidance on when to prefer search_people or list_people instead, and no note that it errors if the id doesn't exist.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /projects/{id}) and implies the embed avoids extra calls, but says nothing about behavior for a nonexistent id or any limit on expansion 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?

Two short sentences with zero filler: the core behavior and the optional expansion lead, and the endpoint reference trails as a compact implementation hint.

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 read tool with full schema coverage and annotations carrying the safety profile, the description says enough about scope and returned content (a project plus optional tags, people, company, tasks, calendar events). No output schema exists, but the description adequately signals the response shape for a simple single-record get.

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

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

Schema description coverage is 100%, so the schema already documents both project_id and the includes enum with its full value list. The description mirrors the includable relations in prose but adds no syntax or format detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('One project by id') and lists the optional embedded relations, which is enough to distinguish it from centralstationcrm_list_projects and centralstationcrm_search_projects that return sets rather than a single record. It stops short of naming those siblings explicitly, so it is clear but not maximally differentiated.

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 'by id' phrasing implies this tool applies when a project id is already known, and 'optionally with' hints that includes are for avoiding follow-up calls. However, it never states when not to use it, nor tells the agent to use search_projects/list_projects first when an id is unknown.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the endpoint mapping ('GET /tasks/{id}'); it says nothing about not-found behavior, error responses, or whether the returned task includes related entities — the kind of context that would add value beyond the structured fields.

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

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

Two very short fragments with zero filler, and the core meaning is front-loaded. It is arguably under-specified rather than bloated, but nothing in the text is wasted.

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

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

For a simple single-parameter getter this is close to adequate, and annotations plus full schema coverage carry most of the burden. The notable gap is the absence of an output schema: the description never hints at what a task object contains, leaving the agent to discover the return shape by calling 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 100% and the single task_id parameter is fully documented in the schema, so the description is not required to compensate. It adds no new semantics about the id (e.g. where to obtain one), which is consistent with the baseline 3 for high-coverage schemas.

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 ('One task by id') and adds the REST endpoint, so the retrieval intent is unambiguous. However it does not differentiate itself from siblings like list_tasks or search_all, so the agent must infer that this is the single-record lookup path.

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 explicit when-to-use statement and no named alternative. The agent can infer 'use when you already have a task id' and that list_tasks is the counterpart, but nothing in the text confirms this or states a prerequisite such as needing a valid id.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that it maps to GET /cal_events, which is consistent with the annotations but reveals nothing new about pagination behavior, result volume, or error conditions.

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

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

Three short sentences with the resource and scope front-loaded, then the filtering capability, then the endpoint mapping. Nothing is redundant or padded.

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

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

For a read-only paginated list tool with zero required parameters and 100% schema coverage, the definition is nearly sufficient. The only gap is that no output schema exists and the description says nothing about the returned event fields or total-count/next_page behavior, which the schema only hints at via the page description.

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

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

Schema description coverage is 100%, so all six parameters (page, perpage, after, before, state, order) are documented in the schema itself. The description echoes the state and date-range concepts but adds no format, default, or interaction detail beyond what the schema provides.

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

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

States a specific verb and resource ("List calendar events") and disambiguates the resource with "appointments, meetings" plus the scope "of the account." No sibling tool covers calendar events (siblings are list_tasks, list_deals, etc.), so the resource alone separates it, though it never explicitly frames that 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?

"Filter by upcoming/old and date range" implies when the filters are useful but gives no explicit when-to-use, when-not-to-use, or alternative tool. An agent must infer that this is the tool for calendar data versus task or project listings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds only the underlying endpoint (GET /companies) and the optional tag filter; it says nothing about whether results are paginated in practice or how 'next_page' behaves.

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?

Four short sentences with the capability declared first and the alternative second; nothing is padded. The trailing 'GET /companies.' is low-value for an agent but harmless.

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-required-parameter read-only list tool with 100% schema coverage and no output schema, the description plus schema gives an agent enough to call it correctly. The only gap is that neither annotations nor description explain the returned collection shape or total-count behavior.

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

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

Schema description coverage is 100%, so page, perpage, order, includes and tag_name are already fully documented. The description restates the tag filter and summarizes the ordering dimensions (name, creation, last update), adding little beyond the enum descriptions.

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

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

States a specific verb and resource ('List companies') and immediately scopes it with the available filter/order options, which separates it from get_company and search_companies. It does not distinguish itself from centralstationcrm_count_records or list_people-style siblings, but the resource 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?

Explicitly routes name lookup to search_companies ('Use search_companies to find one by name'), giving a clear when-to-use-alternative rule. It offers no guidance on when to prefer count_records or search_all, and no note on paging through results beyond the schema hint.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by naming the concrete data fields a deal carries and disclosing the raw GET /deals endpoint, but says nothing about pagination behavior, result volume, or whether includes triggers extra cost beyond the schema's note.

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

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

Three tight sentences, front-loaded with the resource and its payload, then filters, then ordering. Nothing is redundant, though the parenthetical state enumeration duplicates the schema enum and could be trimmed.

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 9 all-optional params, 100% schema coverage, and no output schema, the description's field enumeration helpfully substitutes for the missing return contract. It is close to complete for an agent to call it correctly; only the relationship to search_deals remains unstated.

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

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

Schema description coverage is 100%, so every parameter is already documented, making 3 the baseline. The description does mirror the filter dimensions (company, user, pipeline, state) and ordering dimensions, which aids recall, but it omits includes, page, and perpage entirely and adds no format or interaction detail 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+resource ('List deals') and enumerates the notable fields returned (value, state, pipeline/stage ids, target date), plus the endpoint. It distinguishes itself from get_deal and create_deal implicitly by being a collection query, but never names search_deals or get_deal_stats as the contrasting siblings an agent should weigh.

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 'Filter by company, responsible user, pipeline or state; order by...' conveys the intended usage pattern, but it is purely descriptive of capability rather than prescriptive about when to choose this over search_deals or get_deal_stats. No exclusions or prerequisite notes are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description only restates the endpoint (GET /deal_types) and the inclusion of stages, adding no context on result size, caching, or ordering; with annotations carrying the behavioral burden, a 3 is appropriate.

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

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

Two short sentences: the first declares what is returned, the second explains how to use it. Nothing is padded and the operative content is front-loaded.

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

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

For a zero-param read-only lookup with no output schema, the description covers the essentials: what items come back and that each carries stages plus the ids needed downstream. It could hint at the shape of the response (e.g., id/name/stage list), but nothing required to invoke it is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The mention of ids and stage ids refers to returned values, not inputs, which is harmless.

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

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

States a specific verb and resource ('List the deal types (pipelines)') and clarifies the domain synonym deal types = pipelines, then notes stages are included. An agent can distinguish this from list_deals or get_deal_stats without opening any 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?

Explicitly tells the agent what the returned ids are for: creating deals and moving them between stages, which is a concrete downstream workflow. It stops short of naming alternatives or when-not-to-call conditions, so it lands just below the top.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that this is a paginated GET over a history log aggregated from several record types, which is mildly useful, but it says nothing about default sort, result size, or what a protocol entry contains.

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

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

Three short clauses, front-loaded with what the resource is, then how to filter it. No redundant or filler text.

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

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

For a read-only, fully documented, paginated list tool with annotations and no output schema, the description covers the resource scope and filtering axes. The main residual gap is the shape of a returned protocol entry, which is only hinted at by the enumeration of entry types.

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

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

Schema description coverage is 100%, so every parameter including page, perpage and order is already documented in the schema. The description only restates the four id filters, adding no format or behavioral nuance beyond it — baseline 3 applies.

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

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

The description uses a specific verb and resource and clarifies that 'protocols' encompasses notes, logged emails and other history entries, so an agent knows what data comes back. It doesn't distinguish itself from the sibling get_note or search_all, 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?

Listing the four filter dimensions (person, company, deal, project) implies the usage pattern, but there is no explicit statement of when to prefer this over get_note, search_all, or list_tasks, and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the HTTP endpoint (GET /people), which corroborates read-only behavior but adds little beyond what annotations supply. Nothing is said about pagination limits or volume of results, leaving that to 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?

Three short sentences: capability first, refinements second, sibling routing third. No redundant field enumeration and 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 read-only list tool with fully documented parameters, this covers the essentials. The only minor gap is that the shape of the returned collection (paging envelope, next_page) is not referenced in the description, though the schema's page parameter hints at 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 description coverage is 100%, so every parameter — page, order enum values, perpage limits, includes list, tag_name — is already documented in structured form. The description's mention of tag filtering and ordering is a strictly less precise restatement. Baseline 3 applies when the schema carries the semantics.

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

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

States a specific verb and resource ('List contact people') plus its optional narrowing and ordering scope, and explicitly names search_people as the sibling it is not. An agent can distinguish it from list_companies, list_deals, and search_people without opening any 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?

Gives an explicit routing rule: use search_people to find a person by name, email or phone, implying this tool is for enumerating/browsing. The condition that selects the alternative is named, not left to inference.

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

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

Annotations already establish read-only, open-world, and non-destructive behavior. The description adds the endpoint and some returned fields, but does not discuss pagination, included relationships, or other behavioral details beyond what the schema provides.

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 filtering/ordering, then endpoint. Every sentence contributes useful information without waste.

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

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

Given the rich schema coverage and helpful annotations, the description is mostly complete for a list tool. It could mention pagination or included relationships more explicitly, but the schema covers those details.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds some meaning for tag filtering and ordering, but does not need to compensate for schema gaps, making the baseline 3 appropriate.

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

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

States a specific verb and resource: "List projects," and adds the fields, filtering, and ordering dimensions. It is clear what the tool does, though it does not explicitly distinguish itself from search_projects or get_project.

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 says it can filter by tag and order by date, state, or name, which implies usage. However, it gives no explicit guidance on when to choose this over search_projects or get_project.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — it does not mention that results are paginated, whether the list is complete across pages, or that tags are account-wide rather than scoped to an object type.

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

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

Two short sentences with the purpose front-loaded and no filler. The trailing "GET /tags/list" is largely noise for an agent and is the only sentence not earning its place.

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

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

For a simple, read-only, zero-required-parameter list call with full schema coverage and an output-less contract, this is minimally sufficient. Missing: whether the returned list spans all pages or must be paged, and whether tags are unique strings or attached to entities.

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

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

Schema description coverage is 100% for both parameters (page and perpage), including defaults, ranges and the next_page chaining hint, so the schema carries the semantics. The description adds no parameter context, which is the expected baseline 3 here.

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

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

States a specific verb and resource ("List all tag names used in the account") and clarifies the return is names only, which is useful scoping. There is no competing tag-listing sibling, so no explicit differentiation is needed, though the endpoint string adds nothing an agent can act on.

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 call this versus alternatives (e.g. search_all, list_companies), no prerequisites, and no statement of what the tags are used for. The agent must infer that this is a discovery call to find valid tag values before filtering.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the task-type enumeration and the underlying endpoint, but says nothing about pagination behavior or result volume limits beyond what the schema states.

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

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

Two compact sentences with the scope and filters front-loaded; the trailing 'GET /tasks' endpoint note adds little but costs almost nothing. No wasted prose.

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 7-parameter, no-required-argument list tool with no output schema and read-only annotations, the description covers scope and filters adequately. Pagination and default page size are left to the schema, which handles them well.

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

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

Schema description coverage is 100%, so all seven parameters are already documented with formats, defaults and enum values. The description restates the filter categories (state, date range, user) at a high level without adding syntax or semantics beyond the schema.

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

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

States a specific verb (List) and resource (tasks), and usefully expands 'tasks' to cover to-dos, calls, emails and visits, which is non-obvious domain knowledge. It doesn't explicitly contrast with get_task or list_calendar_events, but the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The filter list ('open/closed state, due-date range and responsible user') implies when the tool is useful, but there is no explicit guidance on when to prefer it over get_task for a single item or search_all for cross-entity lookup.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /users) and the shape of returned records, but says nothing about pagination iteration or response ordering beyond what the schema's next_page hint implies.

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

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

Three short sentences, zero padding, with the resource and returned fields front-loaded before the usage note. Every clause earns its place.

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

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

For a simple read-only list tool with a fully documented schema and no output schema, the description covers what is returned and how the ids are consumed downstream. Only the pagination workflow and the get_current_user alternative 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 100% — page, active and perpage are each documented in the schema with defaults, ranges and the next_page chaining hint. The description contributes no additional parameter meaning, so baseline 3 applies.

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

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

States a specific verb and resource ('List the users of the CentralStationCRM account') and enumerates the returned fields (id, name, email). It is distinguishable from the get_* siblings, though it never explicitly contrasts itself with centralstationcrm_get_current_user.

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 sentence 'Use the ids for responsible-user filters and for assigning records' gives downstream usage context, which implies when to call it. However, there is no explicit when-not guidance and no mention of the get_current_user alternative for the single-user 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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds that matching is full-text and that the endpoint is GET /search, but says nothing about result volume, ordering, or that responses mix record types — notable for a search with no limit parameter.

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

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

Two short sentences, front-loaded with the scope statement; nothing is padded. The trailing 'GET /search' is low-value but harmlessly brief.

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 one-parameter read tool this is close to sufficient, but with no output schema the description should say something about what comes back — particularly that results span four heterogeneous entity types and how they are distinguished — which it omits.

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

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

Schema coverage is 100% with a single required 'term' parameter that is already documented. The description's 'for a term' adds nothing beyond the schema, so the baseline 3 applies — it does not explain matching rules (substring vs word, case sensitivity) that would help shape a query.

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 ('Full-text search') plus the exact scope ('across people, companies, deals and projects'). The enumeration implicitly differentiates it from the entity-specific siblings (search_people, search_deals, etc.), though it never explicitly contrasts itself with 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?

Usage is only implied: an agent can infer this is the cross-entity search versus the per-entity siblings, but the description never states when to prefer it (e.g., 'use when you don't know the record type'). No exclusions or alternatives are named.

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

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

Annotations already declare the safety profile (readOnly, non-destructive, open-world), while the description adds only the HTTP endpoint. It does not add behavioral context such as partial-match semantics, pagination behavior, or what the response contains beyond what the schema and annotations already state.

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

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

The description is two short sentences, front-loads the core purpose, and contains no filler. It is appropriately sized for a simple search tool.

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

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

The tool is simple and the schema is rich, but with no output schema the description does not explain the return shape or pagination response. It also omits sibling differentiation, which matters given list_companies, search_all, and other search_* 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 100%, so all four parameters are already documented in the schema, including 'name' as full or partial company name and pagination details. The description adds no parameter meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description states a specific verb and resource ('Find companies') and clarifies the search key ('by name'), which distinguishes it from get-company operations. However, it does not explicitly differentiate from sibling tools like list_companies or search_all, leaving some ambiguity for an agent choosing among search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'by name' implies the condition for using this tool rather than listing or fetching by ID. But it gives no explicit when-to-use guidance, no exclusions, and does not name alternatives such as list_companies or search_all.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the underlying endpoint ('GET /deals/search'), which is marginally useful; it says nothing about match semantics (substring vs exact), result ordering, or what happens with very short/ambiguous names.

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

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

Two short sentences with no waste and the purpose is front-loaded. The trailing endpoint reference is low-value for an agent but not harmful; the tradeoff is that terseness comes at the cost of guidance.

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

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

For a simple read-only search with full schema coverage and no output schema, the essentials are present. However, nothing is said about result shape, pagination beyond the schema's next_page hint, or behavior on zero/many matches, leaving gaps an agent would want to know.

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

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

Schema description coverage is 100%, so name, page, perpage and includes are all documented in the schema, including the useful 'pass the previous reply's next_page' instruction. The description contributes only 'by name', which is already in the schema – baseline 3 applies.

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

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

States a specific verb ('Find') and resource ('deals') and the matching field ('by name'), which distinguishes it from get_deal (single record by id) and list_deals (enumeration). It never names a sibling explicitly, so differentiation is inferential rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: search when you know part of a deal name. There is no explicit 'use this instead of list_deals when...' guidance, no note about behavior when the name matches many deals, and no fallback if no match is found.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds only the REST endpoint and the email/phone incompatibility rule, which the schema already states per-field; it does not say whether matching is exact, prefix, or fuzzy, or whether an empty result is an error.

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

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

Three short sentences with the searchable fields front-loaded, followed by the minimum-criterion rule and the mutual exclusion. No filler and nothing redundant with the title.

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

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

For a read-only search with full schema coverage and annotations, most needs are met by structured fields. The key missing piece is match semantics (exact vs partial vs case sensitivity) and result ordering/paging behavior, which materially affect how the agent should query and whether it must retry with a different input.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds a constraint the schema cannot express: zero parameters are required yet at least one search criterion must be supplied. That directly affects whether the agent can call the tool legally. It still says nothing about the includes or pagination parameters beyond what the schema documents.

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 (Find) and resource (people) plus the four searchable fields and the endpoint, so the agent knows this is a targeted lookup rather than a listing. It doesn't explicitly contrast with siblings like list_people, search_all, or get_person, so differentiation is inferred from the name rather than stated.

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?

"Give at least one criterion" and "email and phone cannot be combined" give usable invocation constraints. However, there is no guidance on when to choose this over list_people, search_all, or search_companies, and no mention of what to do when a search returns nothing.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds essentially nothing behavioral beyond echoing an HTTP endpoint; it says nothing about pagination traversal or result limits, which are the traits an agent would actually need here.

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

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

Two short sentences, front-loaded with the purpose and free of filler. Nothing could be trimmed without losing content.

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

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

For a simple read-only search with full schema coverage and annotations covering safety, this is barely adequate. There is no output schema, yet the description does not say that results are paginated or how to continue paging, and it omits the sibling-routing context that matters in a toolset this large.

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

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

Schema description coverage is 100%, so the schema already documents name, page, perpage and includes (including pagination chaining and embed options). The description adds no parameter meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb and resource plus the matching criterion ('Find projects by name'), and the endpoint confirms it is a search. It does not, however, distinguish itself from siblings like centralstationcrm_list_projects or centralstationcrm_search_all, which an agent scanning the toolset could easily confuse with it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no mention of alternatives. The description never says to prefer this over list_projects or search_all when the intent is a name lookup, nor does it state any prerequisites, so routing is left entirely to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description still adds real value by disclosing partial-update semantics (unspecified fields are untouched) despite the PUT verb, which would otherwise imply full replacement. It does not warn that background text is overwritten, but the schema parameter description covers that.

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

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

Three short sentences, zero filler, and the most important signal (WRITE) is front-loaded before the behavioral nuance and the endpoint.

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 small mutation tool whose annotations already carry the safety profile, the description plus schema covers what an agent needs to call it correctly. The only gap is that it doesn't say what the call returns, though the absence of an output schema makes that a minor 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 coverage is 100%, so the baseline would be 3, but the line "Only the fields you give are sent" adds meaning the schema does not: optional parameters are omitted rather than cleared. That materially changes how an agent constructs the call.

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?

"WRITE: change fields of a company" names a specific verb and resource, and the resource name distinguishes it from update_deal/update_person/update_task siblings. It doesn't explicitly say to use create_company for new records or get_company for reading, but the verb+resource pairing is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the WRITE marker and the "Only the fields you give are sent" clause, which hints at partial-update intent. However, it never names an alternative (create_company, get_company) or states preconditions such as needing an existing company_id.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the bar is lower. The description adds genuinely useful behavior beyond them: partial-update semantics ('Only the fields you give are sent') and concrete mutation examples, so the agent knows unmentioned fields are preserved rather than cleared.

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

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

Three short sentences, front-loaded with the operation type and the partial-update rule, ending with the endpoint. Nothing is redundant and no sentence is wasted.

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 annotations covering safety profile and a fully described 13-param schema, the description plus schema give an agent what it needs to invoke the tool. The main unaddressed point is what the call returns (no output schema) and any error behavior for an invalid deal id.

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

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

Schema description coverage is 100%, so all 13 parameters including required deal_id, enums and ranges are documented structurally; baseline 3 applies. The description only gestures at current_state and deal_type_stage_id via examples and adds no format or constraint detail 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 and resource ('change fields of a deal') and gives concrete examples of the most common writes (stage move, won/lost state). It is clearly an update tool, distinguishable from create_deal and get_deal, though it never explicitly names those siblings as contrasts.

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 WRITE prefix and the PUT /deals/{id} endpoint, and 'Only the fields you give are sent' tells the agent this is a partial update rather than a replace. There is no explicit when-to-use/when-not guidance or routing to alternatives such as create_deal or list_deal_types for discovering stage ids.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: it is a partial update where only supplied fields are sent and everything else is preserved, plus the underlying PUT endpoint – context an agent would not get from the annotations alone.

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

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

Three very short sentences, front-loaded with the operation type and its most important semantic constraint. 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 an 8-parameter mutation tool with rich annotations and no output schema, the description covers the key behavioral facts: write operation, partial-update semantics, and endpoint. It does not discuss the destructive/replace behavior of fields like 'background' or error/return shape, leaving a small gap.

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

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

Schema coverage is 100%, so the per-field meanings are already documented. The description still adds semantic value by clarifying the partial-update contract ('only the fields you give are sent; the rest stays'), which the schema's property list alone does not establish.

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: 'change fields of a person', with a 'WRITE:' prefix that separates it from the read-oriented siblings (get_person, list_people). It does not explicitly name a sibling to distinguish from create_person or update_company, so it stops short of the top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the word 'change' – an agent can infer this is for modifying an existing person rather than creating one. There is no explicit when-to-use/when-not guidance or reference to a preferred 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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds the non-obvious behavioral fact that this is a sparse/partial update, which meaningfully softens the destructive hint; what it does not explain is what the destructive flag actually implies here (e.g., whether omitted fields can be cleared).

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

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

Three short sentences with the operation type front-loaded as "WRITE", zero filler, and the partial-update rule placed before the endpoint. Nothing can be cut without losing 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 7-parameter mutation with no output schema, the description says nothing about what comes back or how to confirm the change succeeded, and it does not address the destructiveHint meaning. Params and safety hints are otherwise well covered, so this is adequate but with a real gap around result handling.

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

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

Schema description coverage is 100%, so every parameter is already documented, including finished=true/false and fuzzy semantics. The description's example mappings (finished = true to mark done) repeat what the schema says, adding no new meaning, so the baseline 3 applies.

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

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

States a specific verb ("change a task") plus the resource and gives concrete examples of what changing means (mark done, rename, reschedule), which is enough to separate it from create_task and get_task without opening a schema. The endpoint (PUT /tasks/{id}) reinforces the update-only scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Only the fields you give are sent" implies partial-update usage, which is useful, but there is no explicit statement of when to use this versus create_task or get_task, and no stated prerequisite beyond the required task_id in the schema. Usage is implied rather than guided.

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