Copper MCP by usefulapi

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

The annotations only supply destructiveHint=true, which is an unusual signal for a create operation, and the description does nothing to clarify it. It doesn't say what happens on a duplicate domain/name, whether the call is idempotent, what it returns, or what permissions are needed — so it adds almost nothing beyond the annotation and the endpoint string.

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, front-loaded sentences with no filler; the action comes first. The trailing REST endpoint reference is arguably marginal value for an agent, but the description is not 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?

The parameters are fully covered by the schema and the entity is unambiguous, but with no output schema the description never says what comes back (e.g. the created company id) and gives no duplicate-handling or error behaviour. For a mutation tool that is an incomplete but not severe gap.

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

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

Schema description coverage is 100%, so every one of the six parameters (name, tags, details, assignee_id, email_domain, phone_numbers) is already documented in the schema itself. The description adds no syntax, format, or constraint detail beyond that, which is the expected baseline when the schema carries the load.

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

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

States a specific verb ('Create') and resource ('a new company'), which cleanly distinguishes it from the sibling creates for leads, opportunities, persons and tasks. An agent needs no schema inspection to know exactly what this does.

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

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

No when-to-use guidance at all: it doesn't say to search first (copper_search_companies) to avoid duplicates, nor mention any prerequisites such as permissions or required fields. The only context given is the REST endpoint mapping.

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

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

Annotations declare destructiveHint=true, so the description should add context about side effects, reversibility, or permissions. Instead, it only adds the REST endpoint (POST /leads), which is technical but not behavioral. It does not explain what 'destructive' means for a create operation or any other runtime traits.

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

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

Two short sentences with zero waste, front-loading the core action. The REST endpoint in the second sentence is compact and potentially useful for developers, and nothing is extraneous.

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

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

For a 10-parameter create tool with nested objects and no output schema, the description is inadequate. It omits usage context, behavioral implications of destructiveHint=true, and response/error handling, leaving the agent with only the schema and a bare endpoint.

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 input schema fully documents all 10 parameters including nested objects. The description adds no parameter-level meaning, which is acceptable at baseline 3 when the schema does the heavy lifting.

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

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

The description states a specific verb (Create) and resource (lead), immediately distinguishing it from sibling create tools like copper_create_company or copper_create_opportunity. An agent can identify exactly what this tool does without opening the schema.

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

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

The description provides no guidance on when to use this tool versus alternatives such as copper_update_person or copper_search_leads. It merely states the operation without context, prerequisites, or exclusions.

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

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

Annotations cover only destructiveHint=true, so the description's note about Copper-enforced required fields and the underlying REST endpoint adds some useful context. But it says nothing about side effects, duplicate handling, permissions, or what a successful call yields, leaving real gaps for a mutation tool.

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

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

Two short sentences, the purpose is front-loaded, and the requirement note follows. Nothing is padded or 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?

With ten parameters, no output schema, and only a bare destructiveHint, the description should say what is returned (e.g., the created opportunity id) and how the many optional fields behave. Instead it covers only the two required fields, which the schema already handles.

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 ten parameters are already documented in the schema. The description's 'name and primary_contact_id are required' merely restates the required array and adds no format or default information beyond it.

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

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

States a specific verb and resource ('Create a new opportunity (deal)'), which is enough to distinguish it from the other copper_create_* siblings by resource noun alone. It does not, however, explicitly route the agent away from related tools like copper_create_lead or copper_search_opportunities.

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

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

No guidance on when to use this versus alternatives such as copper_create_lead, nor any prerequisite notes (e.g., checking for existing opportunities, needing a contact/company id first). It only asserts what Copper requires.

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 provide only destructiveHint=true, leaving the description to carry most of the behavioral burden. It adds nothing about whether the call is idempotent, what happens on duplicate email/name, permission requirements, or what the response contains (e.g. the new person's id).

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

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

Two short fragments with the action front-loaded and no filler. The REST endpoint reference is mildly useful for API mapping but not necessary for invocation.

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

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

For a nine-parameter creation tool with no output schema, the description is minimally adequate: the schema covers inputs, but nothing explains what is returned, whether creation is idempotent, or which fields matter most. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the schema with clear semantics. The description adds no parameter-level detail beyond the required 'name' implication, so the baseline 3 applies.

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

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

States a specific verb and resource ('Create a new person (contact)') and clarifies Copper's 'person' terminology as 'contact'. It is unambiguous against siblings like copper_create_company or copper_create_lead, but does not explicitly differentiate itself from those alternatives.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as copper_create_lead or copper_update_person. The agent must infer usage purely from the tool name.

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

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

Annotations only supply destructiveHint=true; the description adds nothing about permissions, side effects, or what the created record looks like. 'Copper REST: POST /tasks' merely restates that this is a write call, which the annotations already imply. It does not explain the odd destructiveHint on a create operation or the linked-resource attachment behavior.

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

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

Two very short sentences with the purpose front-loaded and no padding. The REST endpoint fragment is arguably developer noise rather than agent-facing value, but it is brief and does not bury the main statement.

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

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

For a mutation tool with nine parameters and no output schema, the description omits required-vs-optional hints, the record-attachment semantics, and any indication of what is returned. An agent can call it, but only by reading the schema blind to the tool's operational context.

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 nine parameters are already documented in the schema (including the coupled related_resource_id/related_resource_type pair). The description contributes no additional parameter meaning, which is the baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Create a new task'), which cleanly distinguishes it from the sibling create tools (create_company, create_lead, etc.) by object type. It does not differentiate by behavior or scope beyond the noun, so it stays short of a 5.

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

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

There is no when-to-use guidance, no prerequisites (e.g., that an assignee_id must be a valid user, or that attaching to a record needs both related fields), and no mention of alternatives such as copper_search_tasks or copper_get_task. The agent must infer everything from the name.

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

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

The readOnlyHint=true annotation already declares this as a safe, non-mutating read. The description adds the underlying REST mapping (GET /account) and the word 'authenticated,' which hints at an auth requirement, but says nothing about return shape, rate limits, or error behavior. With annotations covering the safety profile, this is adequate but thin.

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

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

Two tight sentences, zero waste, with the core action stated first and the API mapping appended. No redundancy or padding.

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-parameter read with no output schema, the description does its job: it tells the agent what will be retrieved and the underlying endpoint. The only missing piece is any hint of what fields the account details contain, but that is a minor gap for a trivial getter.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies. The schema is empty and fully self-consistent with a no-argument getter.

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: 'Get details of the authenticated Copper account.' This clearly separates it from the entity-specific siblings (copper_get_company, copper_get_person), though it does not name them explicitly. The purpose is unambiguous and front-loaded.

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 name and description — fetch the current account's details — but there is no explicit when-to-use or when-not-to guidance, nor any reference to sibling tools. With zero parameters and one obvious purpose, the omission is minor but still a gap.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the safety profile is covered. The description adds the REST endpoint mapping (GET /companies/{id}), which is mildly useful context, but says nothing about behavior such as error/missing-id handling or what the payload 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?

Two short, front-loaded sentences with no wasted words; the core action leads. The trailing REST-endpoint note contributes little and is the only loosely justified clause.

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 with readOnlyHint annotations, the essential invocation contract is covered. However, with no output schema present, the description gives no hint of the returned company shape or fields, leaving a modest gap for an agent that must reason about the response.

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% – the single 'id' parameter is already documented in the schema, including bounds. The description adds no format, type, or source-of-id guidance beyond what the schema provides, which is the expected baseline.

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

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

States a concrete verb+resource ('Get a single company by id') and even names the underlying REST route, so the agent knows exactly what the tool returns. It does not explicitly differentiate itself from copper_search_companies or the other copper_get_* siblings, which would have pushed it to a 5.

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

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

The phrase 'by id' implies you should use this when you already have a company id, but that condition is never stated as guidance, nor is copper_search_companies named as the alternative for lookup-by-attribute. Usage is inferable rather than spelled out.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying REST mapping (GET /leads/{id}), which is mild orientation value, but says nothing about failure behavior for unknown ids, auth/permission requirements, or what the returned lead record looks like.

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, purpose front-loaded before the implementation detail, with zero 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 one-parameter read tool with full schema coverage and a readOnly annotation, the definition covers everything needed to invoke it. The lack of an output schema and any note on missing-record behavior is a minor gap but not a blocker for simple retrieval.

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 parameter 'id' is already documented as "The lead id." The description's "by id" adds no format, type, or constraint 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 specific verb (get) and resource (a single lead) with the lookup key (by id), which cleanly separates it from the write siblings like copper_create_lead. It does not explicitly name search_leads as the alternative for non-id lookups, so sibling differentiation is only implicit.

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?

"Get a single lead by id" implies the usage context (you already have an id) and implies that search is for other cases, but there is no explicit when-to-use or when-not-to-use statement and no alternative named.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds the underlying REST endpoint (GET /opportunities/{id}), which is mildly useful, but it says nothing about not-found behavior, permissions, or return shape beyond the generic 'get'.

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, zero filler, with the core action front-loaded and the REST endpoint relegated to a supporting clause. 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?

For a one-parameter read-only lookup with full schema coverage and readOnlyHint, this is nearly sufficient. The only real gap is that no output schema exists, so the description could hint at what an opportunity record contains, but that omission is minor for a trivial getter.

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 single 'id' parameter is documented in the schema as 'The opportunity id.' The description adds only the words 'by id', which restates rather than enriches 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 and resource ('Get a single opportunity (deal) by id'), with the 'single' + 'by id' framing implicitly distinguishing it from the sibling copper_search_opportunities / copper_list_pipelines style list tools. It does not name that alternative outright, so it falls just short of full sibling differentiation.

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

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

Usage is only implied: the 'by id' phrasing signals you must already hold an opportunity id, which rules out the search/listing siblings. There is no explicit when-to-use statement, no guidance for what to do when the id is unknown (i.e. search first), and no exclusion notes.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered by structured data. The description adds only the REST endpoint mapping, which is implementation trivia rather than behavior; it says nothing about 404/not-found handling, permission requirements, or what the returned object contains beyond 'a person'.

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 core purpose front-loaded and no filler. The second sentence (Copper REST path) is mildly redundant implementation detail that does not help selection or invocation, keeping it below 5.

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

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

For a one-parameter getter this is nearly sufficient, and the schema covers the parameter. But with no output schema, the description could usefully sketch the returned person shape and note not-found behavior; it leaves those gaps for the agent to discover.

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

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

There is a single parameter with 100% schema description coverage ('The person id.'), so the schema fully carries parameter meaning. The description's 'by id' merely restates this, which is the baseline 3 case.

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

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

States a specific verb (Get) and resource (a single person/contact) scoped 'by id', which cleanly separates it from copper_create_person, copper_update_person, and copper_search_people. It does not explicitly name those siblings as alternatives, so it falls short of 5.

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

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

The phrase 'by id' implicitly tells the agent the required precondition (you must already know the person id), hinting that search_people is the tool to use when you don't. However, no when-to-use or when-not-to-use guidance is stated explicitly, 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?

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description adds the underlying REST endpoint (GET /tasks/{id}), which is mild context, but says nothing about behavior on a missing/invalid id (404 vs empty) or the shape of the returned task.

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 zero filler; the core purpose is front-loaded and the endpoint reference sits in a supporting clause.

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

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

This is a trivial one-parameter read tool with full annotation and schema coverage, so little is required. However, there is no output schema and the description does not characterize the returned task at all, leaving the agent to guess at the response shape, which is a minor but real 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?

With a single parameter at 100% schema description coverage, the schema already carries the semantics ('The task id.'). The description only restates 'by id' and adds no format, range, or sourcing guidance, 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?

The description gives a specific verb and resource ('Get a single task by id') and the 'single ... by id' phrasing implicitly separates it from the list/search siblings such as copper_search_tasks. It never names an alternative explicitly, so it falls short of the 5 tier.

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: the agent can infer it should call this when it already has a task id, but there is no statement of when to prefer this over copper_search_tasks or what to do when the id is unknown. No exclusions or prerequisites 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's main addition is the REST mapping 'POST /activities/search', which usefully explains why a POST-shaped call is nonetheless a read. It does not disclose pagination behavior, result size limits, or permission requirements, and the endpoint mapping is a modest addition at best.

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, front-loaded sentences with no padding; the coverage enumeration is genuinely informative. The trailing REST endpoint note is the least essential part but is brief enough not to bloat the definition.

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

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

No output schema exists, so the description would ideally say something about the return shape (activity records with types/timestamps) or pagination semantics; it does not. All parameters are covered by the schema and the read-only safety profile is covered by annotations, leaving it adequate but not fully self-sufficient for a six-parameter listing tool.

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

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

Schema description coverage is 100%, so all six parameters (page_size, page_number, parent_id, parent_type, min/max activity date) are already documented with units, defaults, and the parent_id/parent_type dependency. The description's phrase 'attached to a record' only loosely gestures at the parent filters and adds no syntax or format 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 (List) and resource (activities), and enumerates the subtypes covered (notes, calls, meetings, system events), which an agent can use to distinguish it from copper_list_activity_types or copper_log_activity. It stops short of naming those siblings explicitly, so sibling differentiation is implied 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?

'attached to a record' implies the scoping condition, and the parent_id/parent_type pairing is visible in the schema. However there is no explicit when-to-use guidance, no statement that listing can be done globally or per record, and no routing to alternatives such as copper_list_activity_types.

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

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

readOnlyHint=true already tells the agent this is a safe read with no side effects. The description adds that results include both user-defined and system types and maps to the Copper REST endpoint, which is useful context but no pagination, ordering, or auth detail.

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 before the endpoint mapping. The 'Copper REST: GET /activity_types' clause is mildly redundant for an agent but cheap and provides API traceability.

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 parameterless list tool with no output schema, the description covers what is returned (user + system types) and why it matters (prerequisite to logging an activity). No output schema means the return shape is not explained, but the tool's simplicity keeps the gap small.

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

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

The tool takes zero parameters, so there is nothing for the description to compensate for; the baseline for a parameterless tool applies. No misleading parameter claims are made.

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 account's activity types') and immediately clarifies scope with '(user + system)'. The clause 'needed to log an activity' implicitly distinguishes it from the similarly named sibling copper_list_activities, which returns activity records rather than the type catalog.

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 'needed to log an activity' gives a clear usage context: call this before copper_log_activity to obtain a valid activity type. It does not name that alternative tool explicitly or state when-not-to-use, so it falls short of a 5.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds that outputs are ids and the underlying endpoint, but nothing about auth scope or pagination. Adequate but not rich.

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; the purpose and downstream use are front-loaded with no filler.

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

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

Complete enough for a no-param read tool: what it returns and why are stated. No output schema exists, so slightly more return-shape detail would help.

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?

Zero parameters, so baseline 4 applies. The description correctly conveys there are no filtering inputs.

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 (sales pipelines and their stages), plus disambiguates against the sibling create_opportunity by explaining the ids are needed to place opportunities.

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

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

Implies a clear prerequisite use-case (fetching pipeline/stage ids before creating opportunities) but does not explicitly name copper_create_opportunity or an alternative tool.

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

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

readOnlyHint=true already establishes the safe-read profile, so the bar is lower. The description adds the return shape (id, name, email) — valuable since there is no output schema — plus the underlying REST call (POST /users/search), which explains why a read maps to a POST endpoint. It says nothing about rate limits or the pagination default, but the schema covers pagination.

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

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

A single front-loaded sentence covering purpose, payload, and use case, followed by a short endpoint reference. No filler or repetition.

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-param, paginated list tool with no output schema, the description supplies the essential return fields and the when-to-use rationale. It is nearly complete; only total-count or ordering behavior is left unspecified.

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 page_size and page_number are already fully documented with defaults and bounds. The description adds no parameter meaning beyond listing returned fields, which is the expected baseline when the schema does the work.

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 (users in the Copper account), and enumerates the returned fields (id, name, email). This cleanly distinguishes it from the many sibling list/search tools that target other resources (activities, pipelines, people, companies).

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?

"useful for resolving assignee ids" gives a concrete when-to-use scenario, which is exactly the agent's decision context. However, it names no alternative tool or exclusion condition, so it falls short of a full when/when-not statement.

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 flag this as a write (destructiveHint=true) and the description reinforces that with the POST /activities endpoint, which does not contradict the annotation. However, it adds nothing about permissions, whether activities are editable/removable after logging, or failure behavior — the annotation bar is lower, but the description contributes only the endpoint detail.

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 action and scope, then the dependency, then the endpoint. No filler or repetition.

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

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

For a 5-parameter write tool with full schema coverage and no output schema, the description covers purpose, prerequisite, and transport. The remaining gap is the mildly surprising destructiveHint=true on an append-style operation, which the description never acknowledges or explains.

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

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

Schema description coverage is 100%, so all five parameters (including parent_type enum and activity_date default) are already documented in the schema; the 3 baseline applies. The description's pointer to copper_list_activity_types for activity_type_id duplicates what the schema field description already says, adding no new 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?

Specific verb+resource ("Log a user activity ... on a record") with concrete examples (note or call) and the underlying REST verb/endpoint (POST /activities). No sibling tool performs the same action, so an agent can distinguish it from copper_create_* and copper_list_activities 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?

It routes the agent to the prerequisite tool ("Get the activity_type_id from copper_list_activity_types"), which is genuine usage guidance. It does not state when-not to use it, nor when to prefer it over copper_create_task for logging a follow-up, so it stops short of a 5.

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

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

readOnlyHint=true already declares the safety profile, so the bar is lower; the description usefully adds that results are paged and clarifies the underlying read via 'Copper REST: POST /companies/search', which pre-empts confusion about a POST-shaped read. It still says nothing about result ordering defaults or empty-filter cost, keeping it from a 5.

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

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

Three short sentences, front-loaded with the purpose and scope; nothing is padded. The trailing REST endpoint note is mildly informational rather than action-guiding, which keeps it from a perfect score.

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

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

For a 10-filter tool with no output schema, the description covers the essentials (optional filters, paged results) but never characterizes what a returned company contains or how pagination interacts with sorting, leaving the agent to infer the response shape.

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

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

Schema description coverage is 100% and all 10 filters (name, city, state, country, tags, assignee_ids, sort_by, sort_direction, page_size, page_number) are documented in the schema itself. The description only restates that filters are optional, adding no syntax or semantics beyond the schema, so the baseline 3 is correct.

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 ('Search/list companies') and makes clear it operates over the company collection rather than a single record. It does not explicitly distinguish itself from search siblings like copper_search_people/copper_search_leads or from copper_get_company, 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?

'All filters optional' implies you can call with no arguments to page through all companies, which is real usage guidance, but there is no statement of when to prefer this over copper_get_company or the other search_* tools, and no exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results are paginated ('returns a page of leads') and maps to the Copper REST endpoint, which is useful context, but it does not say how to page through subsequent results or what the page envelope 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, front-loaded sentences, with the purpose first and the endpoint detail last. The REST endpoint line earns its place only for debugging/parity purposes; otherwise there is no 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?

For a 12-parameter, zero-required search with no output schema, the description covers the essentials (search, optional filters, paged results) but omits page-traversal guidance and result-envelope shape. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so every one of the 12 parameters carries its own description with filters, defaults, and bounds. The description only restates that filters are optional, adding nothing beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource ('Search/list leads') and clarifies that all filters are optional and a page of leads is returned. It is clearly distinguishable from the sibling search_* tools by resource, but it never explicitly names or contrasts them, so it stops short of the top band.

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

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

'All filters optional' implies the tool can be called with no arguments, which is a genuine usage hint. However, there is no guidance on when to prefer this over copper_get_lead or the other search_* tools, and no exclusions or conditions.

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

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

readOnlyHint=true already establishes the safe-read profile. The description adds that results come back as a page and cites the underlying REST endpoint (POST /opportunities/search), which is real extra context, but says nothing about auth requirements, rate limits, or the shape of returned records.

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

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

Three compact clauses with the core purpose front-loaded, then the filter/pagination behavior, then the implementation note. No filler, nothing 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 read-only paginated search with full schema documentation, the description covers purpose and paging, but with no output schema it could say more about what a returned opportunity contains or how paging metadata is exposed.

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 each of the 11 filters is documented in-schema, so the baseline of 3 applies. The description only restates that filters are optional and adds no format or cross-parameter 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 (search/list), resource (opportunities/deals), and adds the helpful synonym 'deals'. It is distinguishable from copper_get_opportunity (single fetch) and copper_create_opportunity, 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?

'All filters optional' usefully signals the tool can be called with no arguments to page through everything, but there is no explicit when-to-use guidance versus copper_get_opportunity or the other copper_search_* tools, and no exclusions.

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

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

readOnlyHint=true already declares the safe-read profile, so the bar is lower. The description adds that results are paginated ('returns a page of people') and that filters are optional, plus the backing REST endpoint. It does not cover pagination limits (which the schema does) or auth/rate-limit behavior, so it is useful but not rich.

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

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

Three short, front-loaded sentences with no padding. The REST endpoint line ('POST /people/search') is marginally low-value for an agent and is the only sentence that does not clearly earn 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 13-parameter read tool with full schema coverage and a readOnly annotation, the essentials are present, and the pagination hint partially compensates for the absent output schema. It is adequate but thin: no guidance on result shape beyond 'a page of people' and no routing context against the 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% — every one of the 13 parameters is documented in the schema with defaults, ranges and match semantics. The description only restates that filters are optional, adding nothing the schema lacks; baseline 3 is correct.

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 ('Search/list people (contacts)') and adds scope detail — all filters optional, returns a page. An agent can distinguish this from copper_get_person (single-record fetch) and copper_search_companies (different resource). It stops short of explicitly naming the alternate tool it is not, so it does not reach 5.

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

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

The only usage signal is 'All filters optional', which implies a bare call acts as list-all. There is no statement of when to prefer this over copper_get_person (known ID) or how it relates to the sibling search tools, leaving the agent to infer the routing.

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

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

readOnlyHint=true already declares this as a safe read, so the bar is lower. The description adds that it returns a paginated result ('a page of tasks') and cites the underlying REST route (POST /tasks/search), but says nothing about result size, auth requirements, or rate limits.

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

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

Three terse sentences, front-loaded with the core purpose, with no redundant prose. The REST-route sentence is borderline metadata but does not bloat the definition.

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 fully-documented, 7-parameter read-only search with no output schema, the definition covers purpose, optionality, and pagination adequately. Only the absence of routing guidance relative to sibling search/get tools leaves 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 description coverage is 100%, so every one of the 7 parameters is already documented in the schema. The description adds no syntax, format, or default information beyond that, matching the baseline for a fully-covered 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 ('Search/list tasks') that clearly distinguishes it from siblings like copper_get_task (single fetch) and copper_create_task. It does not explicitly name those siblings, so it falls short of the top tier.

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 notes 'All filters optional' but gives no when-to-use guidance, no condition for choosing this over copper_get_task or the other search_* tools, and no exclusions. Usage must be inferred from the name alone.

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

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

The annotations already flag destructiveHint=true, and the description adds genuinely useful semantics beyond that with the partial-update guarantee and the underlying endpoint. However, it never reconciles that with the destructive hint or warns which fields behave destructively — the schema silently says tags, emails and phone_numbers are 'Replace'-style wholesale overwrites, which the description does not surface.

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

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

Three short, front-loaded sentences: what it does, the partial-update contract, then the API mapping. No filler and nothing important buried.

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

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

For a 9-parameter mutation with no output schema, the description plus full schema coverage covers the essentials. Minor gaps remain: no note on the destructive array-replacement behavior, permission requirements, or what a successful response contains.

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 input schema and the baseline is 3. The description adds the cross-cutting rule that unchanged fields are preserved, but no per-parameter meaning beyond what the schema states.

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

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

The description gives a specific verb and resource ('Update fields on an existing person') and pins the scope of the change with 'Only provided fields are changed'. The word 'existing' implicitly separates it from copper_create_person, but no sibling tool is named or explicitly contrasted, so it stops short of the top band.

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

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

Usage is implied rather than stated: an agent can infer this is the call for modifying a person that already exists rather than creating one. There is no explicit when-to-use/when-not guidance, no mention of prerequisites (e.g. valid person id, permissions), and no routing to alternatives such as copper_create_person or copper_get_person.

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