Pipeline CRM MCP by usefulapi

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the mutation/safety profile is covered structurally. The description adds the POST endpoint and the meaningful constraint that at least one parent id must be supplied, but says nothing about permissions, retention, or whether the note is visible to other users.

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 clauses, front-loaded with the operation class ('WRITE'), then what is written, then the binding constraint. No filler and no restatement of 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 six-parameter mutation tool with no output schema, the description covers the essentials: what gets created, where it attaches, the parent-id requirement, and the endpoint. Minor gaps remain around side effects (does adding a note touch deal activity timestamps or notifications) and error behavior when no parent id is passed.

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 documentation is already handled and baseline would be 3. The description goes beyond the schema by stating a cross-field requirement that the schema omits: the schema requires only 'content', yet the note must be attached to at least one of deal_id, person_id, or company_id. That is genuine added 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 ('log a note/activity') and resource, plus the attachment scope (deal, person, or company). This clearly separates it from read siblings like pipelinecrm_list_notes and pipelinecrm_get_note, and the 'WRITE:' prefix signals the operation class immediately.

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

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

Usage is implied by the write verb and the attachment targets, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative (e.g., 'to read existing notes use pipelinecrm_list_deal_notes'). The only directive given is an invocation constraint, not selection guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true. The description corroborates the write nature and adds the endpoint, but says nothing about what destructive side effects entail, retry/duplication risk given non-idempotency, or auth/prerequisite needs.

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

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

One dense sentence, front-loaded with the WRITE marker and the subtype split. Every clause (subtype requirements, association, endpoint) carries information; nothing is 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 10-parameter mutation tool with no output schema and full schema coverage, the description covers the subtype distinction, association options, and the write endpoint. It omits return-value expectations and any note on category_id being required by Pipeline CRM, a minor gap the schema partially fills.

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, including the 'Tasks only' / 'Events only' constraints the description repeats. The description adds no format, default, or interaction detail beyond what the schema states, 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 (create) and resource (calendar entry) plus the two subtypes it produces, with their required fields. 'WRITE:' and the POST endpoint make it unmistakably distinct from the get/list/update_calendar_entry siblings.

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

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

Clear guidance on choosing between the task and event subtypes (due_date optional vs start_time/end_time required) and on the optional deal/person/company association. It does not name a sibling alternative (e.g. update_calendar_entry) or state exclusions, 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so "WRITE" adds nothing the structured data didn't. The description omits meaningful behavioral context: duplicate-name handling, whether owner_id/tag_ids must pre-exist, and side effects of creating a company record — all relevant given destructiveHint=true.

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, front-loaded with the operation and then the endpoint; no filler or repetition. It is efficient, though the same brevity is what leaves the tool under-specified for a 14-parameter mutation.

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

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

For a create tool with 14 parameters, nested custom_fields, no output schema, and a destructive annotation, the description covers almost none of the context an agent needs — required-field emphasis, duplicate handling, or what the call returns. The structured fields carry the load, but the description leaves a clear 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 14 parameters and 100% schema description coverage, the schema fully documents each field (name, web, email, custom_fields, etc.), so no description-side compensation is required. The description adds no parameter meaning at all, which lands at the baseline for high coverage.

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

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

The description gives a specific verb and resource ("create a company"), which cleanly separates it from siblings like create_person and create_deal. The "WRITE:" prefix reinforces the mutation intent. It stops short of anything beyond the bare operation, but the purpose is unambiguous.

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

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

There is no guidance on when to create a company versus updating an existing one (pipelinecrm_update_company), nor any precondition such as looking up duplicates first. The "WRITE" tag implies a mutating context but names no alternatives and sets no usage conditions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, so the mutation profile is covered. The description still adds real value beyond them: 'No email is sent to the owner' and the implicit side effect that a new company is created when only company_name is supplied.

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

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

Roughly three compact sentences, front-loaded with the WRITE marker and endpoint, with no filler. Every clause carries information an agent needs.

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

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

For a 13-parameter creation tool with no output schema, the description covers the mutation profile, the key side effect, and the company_name/company_id decision. It stops short of saying what the call returns (e.g. the new deal id), which an agent would have to discover empirically.

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 baseline is 3, but the description adds semantics the schema does not: the fallback relationship between company_name and company_id, and the 'when known' optionality framing for owner/stage/value/close date. It does not cover tag_ids, source_id, person_ids or custom_fields beyond what the schema already says.

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 an explicit 'WRITE: create a deal' verb+resource pair plus the target endpoint (POST /deals), which cleanly separates it from pipelinecrm_update_deal and pipelinecrm_get_deal. There is no ambiguity about what the tool does.

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

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

It gives conditional guidance on inputs ('company or primary contact when known', 'a new company is created from company_name if no company_id is given'), which is useful. But it never states when to choose this tool over siblings like pipelinecrm_create_company or pipelinecrm_update_deal, so tool-selection guidance 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 readOnly=false, destructive=true, idempotent=false, openWorld=true. The description adds genuinely non-obvious context beyond them: that no notification email is sent to the owner, and the underlying POST /people endpoint. It stops short of describing what 'destructive' means in practice or side effects on duplicates.

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 WRITE classification and the key precondition. Every sentence carries distinct information; 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 15-param mutation with no output schema, the description supplies the essential minimum-input rule that the schema's zero required params leave ambiguous, plus the side-effect note about owner email. It is largely complete, though richer guidance on defaults (e.g., the type default) 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?

Schema description coverage is 100%, so all 15 parameters are already documented in the schema. The description restates the name/email requirement but adds no syntax or format meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb ('create') and resource ('a lead or contact'), and the 'WRITE:' prefix flags the operation class. An agent can distinguish this from pipelinecrm_create_company or pipelinecrm_create_deal 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 one concrete invocation precondition ('pass at least a first or last name or an email'), which is useful given zero required params. However, it offers no when-to-use vs when-not guidance or routing to alternatives like pipelinecrm_update_person, leaving usage 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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuine behavioral constraint not in the annotations — results are scoped to 'the deals visible to the user' — but says nothing about pagination, time-window, or whether stages with zero deals appear.

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

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

One sentence plus the backing endpoint, with the aggregate result front-loaded before the summary label. No filler, no restatement of the tool 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?

With no parameters, no nested objects and no output schema, the description carries the burden of describing what comes back, and it does name the two returned values (count and total value) keyed by stage. It stops short of describing the response shape or whether only populated stages are returned, which is 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It doesn't introduce any phantom inputs an agent might expect (e.g., a date filter), which keeps the call surface unambiguous.

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: 'Count and total value of the deals ... in every deal stage', with 'the pipeline summary' as a gloss. This is an aggregate view, which an agent can implicitly tell apart from sibling list_deals/list_deal_stages, but the description 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 through the phrase 'the pipeline summary', which suggests reaching for this tool when an aggregate per-stage view is wanted rather than an enumerated deal list. There is no explicit when-to-use/when-not statement and no named alternative among the many sibling list/get 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. Beyond restating that one entry is returned, the description adds no behavioral context such as 404/not-found behavior, id scoping (user/workspace), or auth requirements; the trailing REST path is a thin implementation 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?

Two short fragments, fully front-loaded, with no filler. The second fragment (the raw GET path) is marginally useful for endpoint mapping but is the least load-bearing part of the text.

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

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

For a single-param read with rich annotations and complete schema coverage, this is close to sufficient. Because there is no output schema, the description could reasonably state what a returned entry contains (field shapes, nested task vs event), 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 description coverage is 100% and there is a single parameter, so the schema carries the semantics and the baseline is 3. The description's 'by id' phrasing adds nothing beyond what the schema's 'Pipeline CRM calendar entry id' already 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+resource ('One calendar entry (task or event) by id') and clarifies that calendar entries can be either tasks or events, which is genuinely useful disambiguation. It is clearly distinguishable from list_calendar_entries, create_calendar_entry, and update_calendar_entry, though it never names those siblings.

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

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

Usage is only implied by the name and the 'by id' phrasing; there is no explicit when-to-use statement or pointer to pipelinecrm_list_calendar_entries as the way to obtain an id. For a simple id-lookup, implied usage is adequate but leaves the retrieval workflow unstated.

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 value by disclosing what the read returns (address, phones, website, owner, tags, custom fields), which the annotations do not, though it omits error/not-found 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 short sentences, no filler, with the resource and scope front-loaded ahead of the source endpoint. 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 one-parameter read tool with no output schema, the description usefully compensates by enumerating the returned fields. The remaining gap is behavioral detail around missing ids or authentication, which is minor for a simple 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 the single parameter is fully documented as 'Pipeline CRM company id.' with positivity/large-integer constraints. The description's 'by id' merely restates 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?

'One company by id' states a specific verb (retrieve) and resource (a single company), and the enumerated fields (address, phones, website, owner, tags, custom fields) make the payload concrete. It implicitly separates itself from pipelinecrm_list_companies via 'by id,' though it never names a sibling explicitly, which keeps it just short of a 5.

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

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

Usage is only implied: the 'by id' phrasing signals this is the single-record lookup rather than a list operation. There is no statement of when to prefer it over pipelinecrm_list_companies or what happens if the id does not exist, so the agent must 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by inventorying what the response contains (including custom fields and the next task), which matters because no output schema exists, but it says nothing about error behavior for an unknown id or any access restrictions.

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 tightly-packed sentence with the return payload front-loaded and the underlying endpoint (GET /deals/{id}) appended for traceability. No filler, no restatement of 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, one-parameter lookup whose safety hints come from annotations, the description is nearly complete, and the field inventory partly compensates for the absent output schema. A note on 404/not-found or missing-permission behavior 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?

With a single parameter and 100% schema description coverage ('Pipeline CRM deal id.', positive integer), the schema already carries the semantics. The phrase 'by id' is consistent with the schema but adds no format or sourcing detail beyond it, so the baseline of 3 applies.

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

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

States a specific verb and resource ('One deal by id') and enumerates the returned surface (owner, company, stage, status, loss/won reasons, tags, custom fields, next task), which cleanly separates it from list_deals and the sibling get_company/get_person tools. It stops short of naming an alternative or restating the id scope, 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?

There is no when-to-use or when-not-to-use guidance; the description never says to prefer this over pipelinecrm_list_deals when the id is unknown, nor mentions prerequisites such as valid authentication or an existing deal. Usage must be inferred entirely from the tool name and the single required 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuine value by enumerating what the read returns (content, author, category, associations, comments) and the underlying endpoint, which is useful given 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 sentences, front-loaded with the resource and return contents, zero filler. The trailing 'GET /notes/{id}' is mildly redundant but compact and anchors the tool to its API call.

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

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

For a single-parameter read tool with full annotation coverage and no output schema, the description supplies the return-field inventory an agent needs. Nothing critical is missing, though error/not-found behavior is unaddressed.

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

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

Only one parameter, note_id, with 100% schema description coverage ('Pipeline CRM note id'), so the schema fully documents it. The description adds nothing beyond restating 'by id', 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 (get) and resource (note/activity) plus the exact fields returned (content, author, category, associations, comments). The 'by id' scope cleanly separates it from the list_notes / list_deal_notes siblings, though no sibling is named explicitly.

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

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

Usage is only implied: fetch a single note when you already have its note_id. There is no explicit when-to-use guidance, no statement of when to prefer pipelinecrm_list_notes or pipelinecrm_list_deal_notes instead, and no prerequisites mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context by listing what the response contains (contact details, company, owner, tags, custom fields) and noting the underlying endpoint, though it says nothing about auth, errors, or whether a missing id returns 404 vs null.

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?

Extremely tight: one front-loaded clause naming the resource and scope, followed by the returned fields and the REST endpoint. No filler sentences and no repetition of 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 simple single-entity getter with one required parameter, full schema coverage, and annotations that already carry the safety profile, the description is nearly sufficient. It even compensates for the absent output schema by summarizing response contents, though it omits any error/not-found behavior.

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

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

The single person_id parameter is fully described in the schema (100% coverage), including type, positivity constraint, and meaning. The description's 'by id' adds no format or syntax 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 resource and scope: a single person (lead or contact) retrieved by id, with an explicit enumeration of the returned data. This clearly distinguishes it from the plural sibling pipelinecrm_list_people and from the other get_* tools that target companies, deals, notes, etc.

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 'by id' – an agent can infer this is the right tool when it already holds a person id and should use pipelinecrm_list_people otherwise. No explicit when-to-use, prerequisites, or named alternatives 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real value by disclosing that the api_key is never returned and by naming the underlying GET /profile endpoint, which is security-relevant context absent from 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 short sentences, front-loaded with the resource and its returned fields, then the security caveat and endpoint. No padding and 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?

There is no output schema, so the description correctly enumerates the returned fields (id, name, admin flag). For a zero-parameter read that is essentially complete; only the absence of an explicit 'use when identifying the current caller' clause keeps it from a 5.

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

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

The tool takes zero parameters, so the baseline is 4. With 100% schema coverage and no inputs, there is nothing further the description could meaningfully add about arguments.

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 exactly what is returned (the user the credential acts as: id, name, account-admin flag), which cleanly separates it from the sibling pipelinecrm_get_user / pipelinecrm_list_users that operate on other users. It stops short of a leading verb+resource statement, but the 'this credential acts as' scoping makes the resource 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 rather than stated: an agent can infer this is the tool to call when it needs to identify the current caller or check admin status. There is no explicit when-to-use, when-not-to-use, or naming of alternatives such as pipelinecrm_get_user for other users.

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 a read-only, non-destructive, open-world read. The description adds genuine value beyond them by disclosing that the api_key is never returned and by citing the underlying endpoint GET /users/{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?

Three short, front-loaded sentences with no filler. Each clause carries distinct information: what it returns, the security caveat, 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 single-parameter read tool with annotations covering the safety profile and no output schema, the description is nearly complete. The only minor gap is absence of explicit routing against list_users.

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 single user_id parameter (integer, positive) is fully documented in the schema. The description only echoes 'by id' and adds no format or constraint detail beyond it, 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 (user) with the retrieval key (by id), and the singular framing implicitly contrasts with the list_users sibling. It doesn't explicitly name that sibling, so it falls 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?

The singular 'One user...by id' implies the use case (fetch a single user when you have its id) versus listing, but there is no explicit when-to-use guidance or named alternative such as list_users. Usage is 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the meaningful domain context that entries are tied to deals, people or companies, but says nothing about pagination behavior or result volume beyond 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?

Two tight sentences with the resource and its definition front-loaded, followed by filters and the endpoint. No filler or redundancy.

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

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

For a read-only list tool with all seven parameters fully documented in the schema, the description covers purpose, filters and endpoint adequately. It omits any indication of the response shape, which is a minor gap given there is no output schema.

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

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

Schema description coverage is 100%, so every parameter including enum meanings is already documented. The description only restates the filter set (kind, owner, dates, status) without adding syntax or format guidance, 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?

Names a specific verb (List) and resource (calendar entries), then defines the two entry kinds, tasks (due date) and events (start/end), plus what they are tied to. This clearly separates it from create/get/update_calendar_entry siblings.

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

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

It enumerates the filter dimensions (kind, owner, date range, status), which implies how to narrow results, but it never states when to choose this over get_calendar_entry or how it relates to the other list_* tools. Usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field inventory and the underlying endpoint, but says nothing about pagination behavior or result-set size limits beyond what the schema already documents.

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 resource and result fields front-loaded; no padding. The trailing 'GET /companies' is endpoint trivia that an agent doesn't strictly need, but it costs almost nothing.

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 list tool with no output schema, the description helpfully enumerates returned fields, but it omits defaults (page 1, per_page 25) and pagination semantics that matter for correct repeated calls. Adequate but leaves real 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 filter (city, name, tag_ids, owner_id, date ranges) and pagination parameter is already fully documented in the schema. The description's mention of address, phones, tags and pipeline totals loosely maps to owner/tag filters and returned fields but adds no syntax or constraint detail.

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

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

States a specific verb pair ('List or search') and the resource ('companies'), plus the field set returned. An agent can tell this is the collection endpoint rather than a single-company fetch, though no sibling (e.g., pipelinecrm_get_company) is named explicitly.

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

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

No when-to-use guidance and no alternatives named. It does not say to use pipelinecrm_get_company for a single record or pipelinecrm_list_company_people for associations, leaving routing to inference from the tool name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered externally. The description adds one useful behavioral detail beyond the annotations — that results mix 'leads and contacts' — but says nothing about ordering, pagination behavior, or empty results. Moderate added value against an already-covered safety profile.

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. The trailing 'GET /companies/{id}/people' restates the operation in transport terms and adds little for an agent, slightly diluting an otherwise tight 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 low-complexity list tool with full schema coverage and safety annotations, the description supplies the operation and the entity scope. No output schema exists, and the description does not describe the response envelope, but for a simple paginated list where paging is documented in the schema this is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents company_id, page and per_page with defaults and the next_page workflow. The description only weakly implies the company_id parameter ('one company') and adds no format or constraint details. Baseline 3 is correct when the schema carries the full param burden.

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) plus the exact resource ('people (leads and contacts) who work at one company'), and the 'one company' scoping distinguishes it from the sibling pipelinecrm_list_people that operates without a company constraint. An agent can pick between the two without opening either schema.

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

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

Usage is implied ('who work at one company') but there is no explicit when-to-use statement, no mention of when to prefer pipelinecrm_list_people or pipelinecrm_get_company instead, and no prerequisites called out. Adequate but leaves selection logic to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuine value beyond them by disclosing the returned shape (author, category, content) and the underlying endpoint, which matters because no output schema exists. It doesn't mention pagination behavior, but the schema's next_page note partly 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?

Two short sentences, front-loaded with the purpose and return fields, with the endpoint appended as compact supplementary detail. 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 simple read-only list tool with full schema coverage and annotations covering the safety profile, the description supplies the essential missing piece — what each note contains. No output schema exists, so this return-shape detail is what completes the picture; only pagination nuance is left implicit.

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

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

Schema description coverage is 100%, so all three parameters (deal_id, page, per_page) are already documented with defaults and ranges in the schema. The description adds no syntax, format, or constraint detail for any parameter, so this sits at the standard 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 gives a specific verb and resource ('List the notes (activities) logged on one deal') and scopes it to a single deal, which implicitly separates it from the sibling list_notes and list_person_notes. It stops short of naming those siblings explicitly, so an agent must infer the distinction rather than being told.

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 phrase 'logged on one deal' — the tool is for notes attached to a specific deal — but there is no explicit guidance on when to prefer it over pipelinecrm_list_notes or pipelinecrm_list_person_notes. No exclusions or prerequisites are stated, so the agent must derive routing from the scope wording 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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value on top of that by disclosing the shape of the result (id, name, and which pipeline is default), which matters because there is no output schema. It stops short of describing pagination behavior, 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?

One tight sentence followed by the raw endpoint, with the most important information (what is listed, and what comes back) front-loaded. The trailing 'GET /admin/deal_pipelines' is developer-facing noise rather than agent-helpful content, which keeps it off a 5.

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

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

For a zero-required-parameter read-only list tool with full schema coverage and annotations, the description plus structured data is nearly sufficient, and the added return-field summary compensates for the absent output schema. Only pagination/result-count behavior is left unaddressed, a minor gap.

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

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

Schema description coverage is 100%: page and per_page are both documented with defaults, ranges and the next_page chaining hint. The description adds nothing beyond the schema about these parameters, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List the deal pipelines') and adds useful scope detail: each pipeline has its own stages, and the reply carries id, name and the default flag. It implicitly separates itself from pipelinecrm_list_deal_stages, though it never names that sibling 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?

There is no statement of when to reach for this tool versus pipelinecrm_list_deal_stages or pipelinecrm_deal_totals_by_stage, and no prerequisites or exclusions. Usage is only inferable from the plain 'list' framing, which is the same shape the calibration MID example scored 2 for.

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 one genuinely useful behavioral fact not in the schema — that money values return as decimal strings — plus the underlying endpoint (GET /deals), but says nothing about pagination behavior or result shape, so it is a modest add over 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?

Two sentences, front-loaded with the core purpose before the filter inventory. The field enumeration is somewhat dense but each sentence carries distinct information and there is no filler.

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

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

For a 20-parameter list tool with no output schema, the description covers scope, filtering surface and the one non-obvious return detail (decimal-string money). It omits anything about total counts or pagination semantics, but pagination parameters are self-documented in the schema, leaving only minor 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 20 parameters are already documented with formats, ranges and cross-references. The description restates the filterable dimensions at a high level ('value range', 'created, expected-close, closed or modified dates') without adding syntax or defaults beyond the schema, 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+resource ('List or search deals') and enumerates the dimensions returned and filterable, so an agent can tell it apart from pipelinecrm_get_deal (single record). It never names a sibling alternative such as pipelinecrm_deal_totals_by_stage, so differentiation is implicit rather than explicit.

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 filter list (search when you need a filtered set), but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives like the aggregate totals tool or the single-deal getter.

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, destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the concrete payload fields and the underlying endpoint, though it says nothing about pagination limits, auth scope for /admin, or rate limits.

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

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

Three short sentences with zero filler, front-loading what is returned before the practical use case and the endpoint. Nothing could be trimmed 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?

With no output schema present, listing the returned fields is the right compensation and is done well. It falls short of fully self-contained by not explaining the paginated response shape (the schema's next_page reference) or that /admin implies elevated permissions.

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

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

Schema description coverage is 100%, with page and per_page already fully documented including defaults and bounds, so the baseline is 3. The description adds no pagination guidance beyond the schema and only alludes to ids without parameter-level detail.

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

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

The description gives a specific verb (List) plus resource (deal stages) and enumerates the returned fields (id, name, default win probability, parent pipeline), which cleanly separates it from sibling list_deal_pipelines and deal_totals_by_stage. An agent can tell what this returns 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 offers downstream context ('Use the ids to filter or move deals'), implying the stages feed other deal operations, but never states when to choose this over list_deal_pipelines or deal_totals_by_stage, nor any prerequisite. Usage is implied rather than prescribed.

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 by structured data. The description adds the GET /admin/<kind> endpoint and the 'one set per call' scoping, but says nothing about return shape (id/name pairs) or rate/permission constraints. With annotations doing the heavy lifting, this is a reasonable 3.

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 purpose clause is correctly front-loaded, but the inline enumeration of all 13 kind values duplicates the schema's enum verbatim, consuming most of the description's length without adding information the schema does not already carry.

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

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

For a read-only listing tool with no output schema, the description covers purpose, endpoint, and the kind vocabulary, and pagination is handled in the schema. It stops short of describing the returned id/label structure, which would be the one 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 description coverage is 100%, so page, per_page, and kind are already fully documented in the schema. The description restates the kind enum rather than adding format or constraint detail beyond it, 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 one set of account lookup values') and immediately clarifies the downstream purpose ('to get ids for filters and writes'). The enumerated kinds make it unambiguous versus siblings like list_deal_stages or list_deal_pipelines, which return pipeline structure rather than flat lookup vocabularies.

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

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

Clearly conveys when to reach for it: to resolve ids for filters and write operations. It does not name an alternative or state exclusions (e.g., when a domain-specific listing tool would be preferred), which keeps it 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the terminology mapping and the at-least-one-ID constraint, but says nothing about pagination behavior or result volume beyond what the schema's page/per_page fields already imply.

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 with the entity scope and the mandatory-ID constraint front-loaded; every clause carries information. The trailing 'GET /notes' is minor boilerplate but costs little.

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 list tool with no output schema and no required parameters, the description covers the essential invocation constraint and the filter surface, leaving pagination details to the schema where they belong. The one gap is sibling disambiguation, which the description never addresses.

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

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

Schema description coverage is 100%, so all 11 parameters are already documented in the schema. The description's filter list (text, category, author, created date) is a prose restatement of query, category_id, author_id and created_after/before with no added syntax or edge-case detail, so the baseline of 3 applies.

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

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

States a specific verb and resource (list notes), names the entity types they attach to, and clarifies the terminology mismatch with the CRM app ('called activities'). It does not, however, differentiate from the close siblings pipelinecrm_list_deal_notes and pipelinecrm_list_person_notes, which an agent could easily confuse with this tool.

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 constraint 'Pass at least one of deal_id, person_id, company_id' is genuine, actionable usage guidance that tells the agent how to invoke it correctly. Beyond that it only enumerates filter dimensions and never states when to prefer this over the entity-specific siblings list_deal_notes / list_person_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, destructiveHint=false and openWorldHint=true, so safety and mutation behavior are covered. The description adds only 'GET /people', which is mildly useful, and says nothing about pagination limits, rate limits, or the shape of results beyond the field list. With annotations carrying the safety profile, this modest addition merits a 3.

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 front-loaded sentences with essentially no waste: the resource and fields come first, the search-vs-filter hint second, the endpoint last. The one minor redundancy is re-listing fields that the schema already names.

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 16-parameter read-only list with a fully documented schema and no output schema, the description need not explain return values. It covers purpose, filtering, and the endpoint adequately; the only gap is the absence of pagination/next_page guidance, which the schema supplies at the parameter level.

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 every parameter's matching semantics and defaults. The description's mention of the searchable fields (name, email, company name) and filterable attributes duplicates rather than extends 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 ('List or search') and resource ('people (leads and contacts)'), and enumerates the salient fields available (email, phones, position, company, owner, lead status, tags). It is clearly distinguishable from siblings like pipelinecrm_list_companies and pipelinecrm_list_deals, and even from the narrower pipelinecrm_list_company_people.

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 search for a quick match... or filter precisely' gives useful conditional guidance, but only about how to use the parameters, not when to select this tool over alternatives. It never says when to prefer pipelinecrm_get_person for a single known record or when to use the list_company_people variant, so routing guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the REST endpoint (GET /people/{id}/deals), which hints at read semantics but discloses nothing new about pagination, rate limits, or result scope.

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 purpose front-loaded and the endpoint as a compact secondary detail. 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 paginated list tool with full schema coverage and annotations carrying the safety profile, the description is nearly sufficient. The one gap is that no output schema exists and the response shape (deal fields, next_page handling) is never described, though the schema's pagination wording partially compensates.

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 person_id, page, and per_page are already documented including defaults and the 'pass next_page' pagination hint. The description adds no parameter meaning beyond the schema, 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 (List) and resource (deals) with the key scoping qualifier 'one person is associated with', which distinguishes it from the broader pipelinecrm_list_deals. It stops short of explicitly naming that sibling, so the differentiation is inferable 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?

The person-scoped framing implies when to reach for this tool (per-person deal lookup), but there is no explicit when-to-use guidance, no mention of pipelinecrm_list_deals as the alternative for all deals, and no 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered and the description doesn't contradict it. The description adds the REST endpoint path but nothing about result ordering, whether notes include activity subtypes, or pagination behaviour 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 short sentences with the purpose front-loaded and no filler. The trailing endpoint reference is mildly redundant with the structured fields but costs almost nothing.

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?

A read-only, single-scope list tool: annotations carry the safety profile, the schema documents every parameter, and no output schema means return-shape detail isn't required. Only the absence of any routing against list_notes/list_deal_notes keeps it from being fully complete.

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

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

Schema description coverage is 100% — person_id, page and per_page all carry clear inline descriptions including the 'Pass the previous reply's next_page' chaining hint. The description adds no parameter detail, so the baseline 3 applies.

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

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

States a specific verb and resource — 'List the notes (activities) logged on one person' — plus the underlying endpoint GET /people/{id}/notes, which pins down the exact scope. It implicitly separates itself from list_notes and list_deal_notes via 'on one person', but never names those siblings in contrast.

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 scoping phrase 'logged on one person'; an agent can infer this is the per-person variant but gets no explicit rule for when to prefer it over pipelinecrm_list_notes or pipelinecrm_list_deal_notes. No prerequisites, no when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the exact returned fields and the security-relevant constraint that 'api_key values are never returned', which an agent cannot infer from the structured data.

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

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

Three compact sentences that front-load the purpose, then the returned fields, then the security note. The trailing 'GET /users' endpoint is mildly redundant but consumes almost no space and causes no harm.

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

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

With no output schema, enumerating the returned fields and the api_key exclusion is exactly the compensation needed, and pagination is handled by the schema's next_page hint in the page parameter. An agent has enough to call it correctly; only explicit alternative-routing guidance is missing.

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

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

Schema description coverage is 100%, so page, per_page, email and including_inactive are fully documented in the schema itself. The description says nothing additional about these filters; per the rubric baseline, 3 is correct 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 ('List') and resource ('users of the Pipeline CRM account'), and enumerates the returned fields (id, name, email, team, admin flag). This clearly separates it from the sibling get_user (single user) and other list_* tools that target different resources.

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

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

Provides a downstream usage note—'Use the ids as owners of deals, people and companies'—which implies why an agent would call this. However, it never states when to prefer this over get_user or list_people, nor any preconditions, so the usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-annotation context: this is a partial update where 'only the fields you pass change'. It does not mention permission requirements or failure behavior for an invalid id, and 'PUT' sits awkwardly beside the claim of partial-update semantics.

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 marker and the resource front-loaded. The partial-update constraint and the one high-value parameter hint are packed into the minimum space.

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 full schema coverage and annotations covering read/write, idempotency and destructiveness, the description supplies what the structured fields cannot: that the operation is a merge-style partial update. No output schema exists, but nothing about calling it correctly is left unknown.

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% (8 of 8 params documented, including the task-vs-event distinctions on due_date/start_time/end_time), so the baseline is 3. The description's only parameter note, 'Pass complete: true to mark a task done', merely restates the schema text and adds no new meaning.

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

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

States a specific verb and resource ('WRITE: change a task or event') and pins the endpoint ('PUT /calendar_entries/{id}'), which is enough to separate it from the read siblings get_calendar_entry/list_calendar_entries. It never names create_calendar_entry or update_* siblings explicitly, so the 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?

Usage is only implied: an agent can infer this is for modifying an existing entry because an id is required. There is no explicit statement of when to prefer this over create_calendar_entry, get_calendar_entry, or the other update_* tools, and no prerequisites (e.g. entry must already 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=false, destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious context: partial-update semantics ('only the fields you pass change') and the concrete endpoint (PUT /companies/{id}). It stops short of explaining what is destroyed (e.g. tag_ids replacing the whole list) or auth/error behavior, 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?

A single compact sentence with the mutation type front-loaded, the key semantic in the middle, and the endpoint last. No filler, no repetition of schema details.

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 15-parameter mutation with a nested custom_fields object, full schema coverage and rich annotations, the description supplies the one thing structured data cannot: the partial-update contract. Not all gaps are closed (clearing fields, list-replacement behavior for tag_ids), and with no output schema it says nothing about what is returned, so 4.

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

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

Schema description coverage is 100% with all 15 parameters documented in-schema, so the baseline is 3. The description adds one meaningful rule beyond the schema, namely that omitted fields are left untouched, but gives no per-parameter guidance (e.g. how to clear a value, or that tag_ids is a full replacement list).

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 company') and prefixes it with 'WRITE:', which distinguishes it at a glance from pipelinecrm_get_company and pipelinecrm_list_companies. It does not explicitly name a sibling or contrast with pipelinecrm_create_company, so 4 rather than 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 clause 'only the fields you pass change' gives an implicit usage rule (pass only what you intend to modify) and the PUT endpoint signals the target path. However, there is no stated when-to-use versus pipelinecrm_create_company, no prerequisites, and no exclusions, so usage remains implied rather than explicit.

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

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

Annotations already declare it a non-read-only, destructive, idempotent write, so the bar is lower. The description still adds real behavior beyond that: partial-update merge semantics, the side effect that closing via probability triggers won/lost status, and the non-obvious note that no email is sent to a new owner.

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

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

Front-loaded with a 'WRITE:' risk marker, then a tight sequence of clauses with no filler. Every sentence carries an operational rule; the trailing 'PUT /deals/{id}' is useful endpoint context.

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

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

For a 20-parameter mutation tool with a nested custom_fields object and no output schema, the description covers the highest-risk behaviors well. It omits how arrays (tag_ids, person_ids) replace rather than append, though the schema itself documents that.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds cross-field semantics the schema doesn't carry — that won/loss reason ids should accompany a probability-driven close — and re-emphasizes stage_id and archived usage, going modestly beyond the per-parameter docs.

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 'WRITE: change fields of a deal' — specific verb plus resource — and immediately scopes it as a partial update ('only the fields you pass change'). This cleanly separates it from pipelinecrm_create_deal and the read-only pipelinecrm_get_deal siblings.

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

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

Gives explicit conditional guidance for the non-obvious cases: use stage_id to move stage, set probability to 100/0 to close won/lost (and supply reason ids), and archived: true to archive. It does not, however, name an alternative sibling or state when not to use this 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?

Annotations already declare write/idempotent/destructive/open-world, so the safety profile is covered. The description adds a trait annotations cannot express: partial-update semantics ('only the fields you pass change'), which is critical for an agent deciding what to send. It does not warn that list-valued fields like tag_ids replace the whole list, but the schema field descriptions cover 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 compact clauses and an endpoint, all front-loaded: write marker first, partial-update rule second, conversion hint third. No sentence is redundant given how much is packed into so few words.

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

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

For a 16-parameter mutation with full schema coverage and no output schema, the description supplies the essentials: mutation type, partial-update behavior, conversion path, and endpoint. No return-value explanation is needed since no output schema exists; only a list-replacement caveat would strengthen it, and the schema already flags tag_ids as a 'full list'.

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% across 16 parameters, so the schema carries the burden; baseline is 3. The description only elaborates on the 'type' parameter (lead-to-contact conversion), which the schema already frames as 'Convert the record to a Lead or a Contact', so the added meaning is marginal.

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') plus the update semantics ('only the fields you pass change') and the underlying operation (PUT /people/{id}). It is clearly distinguishable from create_person and the other update_* siblings by resource. The only shortfall is that it never explicitly contrasts itself with a sibling, which the name already largely handles.

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 one genuine usage rule ('Pass type Contact to convert a lead') and implies partial-update usage, but offers no when-to-use vs. when-not guidance and no pointer to alternatives such as create_person for new records. Usage is inferable rather than stated.

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