HubSpot MCP Extended

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation1/5
The tool names are raw API paths with placeholders like 'objtype' and 'var', and there are multiple v3/v4 versions of the same operations (e.g., get-crm-v3-objects-objtype-objid_objid vs get-crm-v4-objects-objtype-objid_objid). Generic objtype tools overlap with specific object type tools (quotes, invoices, line_items), and descriptions are often just 'Read' or 'Archive', making accurate selection nearly impossible.
Naming Consistency3/5
All tools follow a uniform pattern of HTTP method + hyphenated path segments, which is consistent. However, the heavy use of vague placeholders like 'objtype' and 'var', and the mixing of generic and specific object types in the same pattern, reduces readability and predictability.
Tool Count1/5
With 106 tools, the set is far beyond what an agent can effectively navigate. Many tools are near-duplicates, such as v3/v4 variants and generic vs specific object type versions of the same CRUD operations, so most do not earn their place.
Completeness4/5
The tool set comprehensively covers CRM object operations: CRUD, batch, search, upsert, associations, properties, schemas, and specific object types like quotes and invoices. The generic objtype tools allow any object type, so core workflows are supported, though the redundancy of v3/v4 and generic/specific tools makes the surface bloated.
Average 2.6/5 across 106 of 106 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on October 14, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full responsibility for disclosing behavioral traits. 'Delete' gives zero information about what is deleted, whether it is destructive or irreversible, permissions required, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single word, but this is under-specification rather than effective conciseness. The structure lacks any useful information, making it too sparse to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter deletion tool with no annotations, output schema, or meaningful schema descriptions, the description must provide substantial context. 'Delete' is completely inadequate for understanding the tool's purpose, usage, or effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, each parameter description is merely 'Path parameter X', adding no semantic meaning beyond the parameter name. The description 'Delete' does not clarify how fromObjectType, toObjectType, or associationTypeId relate to the deletion operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete' merely restates the verb in the tool name without specifying what resource or operation it targets. The tool name suggests deleting CRM v4 association labels, but the description provides no object or action detail, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools, such as put/post/get labels or batch archive operations. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description 'Delete' does not disclose whether the operation is destructive, permanent, requires special permissions, or has side effects. The description carries full burden but reveals nothing about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word, which is extremely concise, but it is under-specified. Conciseness should not sacrifice all substance; this fails to earn its place because it repeats the verb from the name without adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters, no output schema, and no annotations, yet the description provides no operational context. It is completely inadequate for an agent to understand when or how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, each parameter description is merely 'Path parameter X', which conveys no semantic meaning. The tool description adds no additional information about what these parameters represent or how they relate to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Delete', which is a tautology of the verb already present in the tool name. It does not state what resource is being deleted (e.g., associations between CRM objects) or provide any distinguishing detail from sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling delete/association tools. The description provides no context about intended use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It provides none: no mention of what is created, side effects, idempotency, permissions, or return values. The only 'behavioral' content is a misleading example that implies creating standard CRM objects, not association definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the single sentence plus example is under-specified. It includes an irrelevant example that does not match the tool's actual inputs, wasting the limited space. There is no structure or front-loaded clarity; the 'Create' verb is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three required parameters, nested array structure) and the lack of annotations or output schema, the description is completely inadequate. It does not explain how to construct a valid request, what the path parameters mean, or the purpose of the inputs. The provided example is incompatible with the schema, leaving an agent without sufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the schema descriptions are generic ('integer parameter', 'string parameter'). The description's example uses 'properties' with 'firstname'/'lastname'/'email', but the schema requires 'category', 'typeId', and 'maxToObjectIds' inside 'inputs'. It also refers to a 'body' parameter that does not exist in the schema, actively misleading rather than adding meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Create', which merely echoes the tool name's '_create' suffix. It fails to identify the resource (association definition configuration) or the operation's scope, and does not distinguish it from the sibling '_update' tool. The example about creating contacts with firstname/lastname is unrelated to the actual schema, adding confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get/update/purge variants. The statement 'REQUIRES body parameter' is not a usage guideline and conflicts with the actual schema requiring path parameters and 'inputs'. No context about prerequisites, typical use cases, or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only says "List" and offers nothing about response format, pagination, error conditions, or the fact that it is a read operation. This is a severe lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single word is not concise; it is under-specified. There is no informative content to judge structure or front-loading. The entire description is a placeholder that should have been a sentence or two.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has three required parameters, no output schema, and no annotations. The description does not explain the purpose, parameters, return value, or when to use it. It is completely inadequate for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the parameter descriptions are merely 'Path parameter objectId', etc., which add no real meaning. The description itself does not explain how objectType, objectId, and toObjectType relate to the association query. The tool name gives some hints, but the description fails to compensate for the empty schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just the word "List", which does not state what is being listed. It fails to identify the resource (CRM associations) or differentiate from sibling tools like create or delete association operations. The name is more informative, but the description itself is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as put-crm-v4-objects-objtype-objid-associations-var-var_var or delete-crm-v4-objects-objtype-objid-associations-var-var_var. The description provides no context about its role as a read-only retrieval operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It does not explain whether this is a soft delete (archive) or permanent delete, whether it is reversible, what permissions are needed, or what the response looks like. The word 'Archive' alone is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One word is not concise; it is grossly under-specified. There is no structure or useful information, so this is not an example of efficient conciseness but rather a lack of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete/archive operation with no annotations, no output schema, and only one-word description, the tool is completely inadequate. The agent lacks essential context about side effects, error cases, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has descriptions for both parameters ('Path parameter objectId', 'Path parameter objectType'), but these are placeholders with no real semantic meaning. The tool description adds nothing, so an agent cannot infer what objectType values are accepted or how objectId should be formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is just 'Archive'. It fails to specify the resource (the CRM object identified by objectType and objectId) or the action clearly. This is essentially a tautology of the tool's name suffix and does not distinguish from sibling batch-archive tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this single-object v4 archive versus the many sibling batch-archive or delete alternatives. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Read' says nothing about whether this is a safe read operation, required permissions, side effects, pagination, response format, or error behavior. It discloses nothing beyond the HTTP method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One word is extreme under-specification, not conciseness. There is no useful information to be front-loaded, and the description fails to earn its place as a meaningful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, a required invoiceId, no output schema, and no annotations, the description is completely inadequate. It does not explain what the tool returns, how parameters interact, or any filtering/selection behavior. The schema exists but the description adds no contextual glue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all six parameters, so the baseline is 3. The description adds no parameter-level value, but the schema fully compensates, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is the single word 'Read', which is a tautology of the HTTP GET verb and provides no specific information about what resource is being read. It does not distinguish this tool from the many sibling tools for invoices, quotes, line items, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get-crm-v3-objects-invoices_invoices (list) or post-crm-v3-objects-invoices_invoices (create). No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description contains no behavioral information such as read-only status, pagination, response format, or error conditions. The single word 'List' offers no transparency beyond the operation's basic nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Under-specification is not conciseness. A one-word description omits essential information and provides no value, earning a low score despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's CRUD context, one parameter, and no annotations or output schema, the description is entirely inadequate. An agent cannot determine the tool's function, expected inputs, or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the objectType parameter, but its description 'Path parameter objectType' is itself minimal. The tool description adds no information about acceptable values or how the parameter impacts the returned data, so it does not enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is the single word 'List', which does not specify what is being listed or any distinguishing scope. It essentially restates the action implied by the tool name without adding resource details, making it impossible to differentiate from sibling listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get-crm-v3-objects-objtype-objid_objid or the v4 listing tool. The description lacks any context on suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description 'Update' discloses zero behavioral traits. It does not mention side effects, required permissions, reversibility, or any operational implications of the mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification, not effective conciseness. It lacks all necessary context and fails to communicate the tool's purpose or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, no annotations, and a one-word description, the tool is completely underspecified. It provides no meaningful assistance to an agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. However, the schema descriptions are largely generic placeholder-like ('string parameter'), and the tool description adds nothing beyond the schema. The baseline applies because the schema at least lists all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Update' with no resource specification. It fails to state what is being updated and does not distinguish from sibling tools like delete or get labels. It is essentially a bare verb with no substantive content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description gives no context for appropriate usage, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Create' reveals nothing about idempotency, side effects, required permissions, or consequences of overwriting existing associations. The PUT method in the name suggests replacing associations, but the description does not confirm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, consisting of a single word 'Create'. This is not genuine conciseness but rather a lack of useful information, similar to the 'Process' example that scored 2.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex tool with 5 required parameters, a nested body array, and no output schema, the description is grossly incomplete. It does not explain the purpose, the relationship between parameters, or any behavioral caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description, including the body's items with associationCategory and associationTypeId. However, the description adds no semantic meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create' is a generic verb with no resource or context. It does not state that this tool creates associations between CRM objects, failing to distinguish it from the many sibling post/create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like delete-crm-v4-objects-objtype-objid-associations-var-var_var and get-crm-v4-objects-objtype-objid-associations-var_var clearly perform related operations, but the description gives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It merely says 'Create' and shows an example, but fails to mention that this creates associations, any side effects, auth requirements, idempotency, or response format. The example even contradicts the schema, making the behavior more confusing rather than transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which might seem concise, but the single sentence and example are underspecified and misleading. The example does not align with the schema and therefore wastes space. It lacks a clear structure that front-loads core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested input schema (from, to, types), no output schema, and no annotations, this description is severely incomplete. It does not explain the association concepts, the structure of inputs, or how fromObjectType/toObjectType relate to the batch operation. The agent cannot reliably invoke this tool based solely on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has descriptions for all parameters, these are generic ('Path parameter toObjectType', 'string parameter') and the tool description adds no meaningful semantic context. Worse, the example provided uses a 'properties' field that does not exist in the schema, directly misleading the agent about what parameters to pass. The description fails to compensate for the schema's lack of explanatory detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create.' which is vague and does not specify what resource is being created. The tool name suggests batch-creating associations between CRM objects, but the description refers to 'objects to create' and gives an example with contact properties (firstname, lastname, email) that contradicts the actual input schema for associations (from, to, types). Thus the purpose is unclear and misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling batch-create tools (e.g., v3 vs v4, objects vs associations). The description only mentions a required body parameter, which is a basic requirement rather than situational usage guidance. It does not state prerequisites, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided and a one-word description, the tool is completely opaque. It does not disclose whether this is a read-only operation, pagination behavior, response format, or any side effects. For a GET-like tool, the agent is left without essential safety and behavior information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, not succinctly informative. A single word might be concise, but it omits all necessary context. It does not earn its place because it adds almost no value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has six parameters, no annotations, no output schema, and a one-word description. It is completely inadequate for an agent to understand what the tool does, when to use it, or what to expect in the response. The description needs to explain the resource, pagination, and parameter behavior, and it does none of this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all six parameters, so the schema already provides full parameter semantics. The description adds no additional meaning. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not compensate or enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only the word "List", which is a generic verb with no resource identified. It does not state that this tool lists CRM quotes objects, making the purpose extremely vague. It fails to distinguish from the many other list endpoints in the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling alternatives such as get-crm-v3-objects-quotes-var_var (retrieve a single quote) or post-crm-v3-objects-quotes-search_search (search quotes). The description does not mention exclusions, prerequisites, or alternative use cases, so it provides zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but 'Update' reveals nothing about mutation semantics, partial versus full update, idempotency, permissions, or return values. This is a critical gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Update' is extremely concise, this is under-specification rather than effective brevity. It is shorter than the tool name and provides no structural benefit, forcing the agent to rely entirely on schema and siblings for meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has nested objects, no output schema, and no annotations, the description must provide substantial context. A single word 'Update' is completely inadequate for an agent to understand the operation's scope, prerequisites, or return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a description: quoteId is a path parameter, idProperty identifies unique property, and properties are key-value pairs. The description adds no additional parameter detail, but the schema already carries the burden, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is the single word 'Update,' which is a tautology of the tool's PATCH verb. It does not specify the resource (quotes) or anything about what is updated, making it impossible to distinguish from the many sibling patch tools like patch-crm-v3-objects-invoices-var_var.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of criteria for using this quotes-specific patch, nor any exclusions or alternative tool references. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must clarify safety and side effects. It does say 'Read', implying read-only, but it fails to disclose required fields (objectType, archived) or explain the structure of the body. The example contradicts the input schema, creating behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though brief, the description's example is inaccurate and takes up space without conveying correct usage. The first sentence is clear but the rest is misleading, so the conciseness is not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, and with a confusing input schema, the description is far from complete. It does not explain what a 'batch of properties' means, how the response is structured, or how objectType and archived factor in. The tool is essentially unusable as documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaningful semantics beyond the schema's generic descriptions. The example introduces 'properties' and 'propertiesWithHistory' fields that are absent from the schema, while the schema's 'inputs' is described as an array of property names only. This actively confuses parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Read a batch of properties' but the example uses object IDs and properties to retrieve, which matches the sibling tool 'post-crm-v3-objects-objtype-batch-read_read' rather than a property-definition read. This ambiguity makes it unclear whether the tool reads property definitions or property values, and it fails to distinguish from closely related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like the object batch-read tool. The example actually points to a different tool's usage (object IDs and property values), misleading the agent about the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'Archive'. It doesn't clarify whether this is destructive, reversible, requires specific permissions, or what happens to the line item. The description carries the full burden and fails to add any transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A one-word description is extremely concise but not informative. It under-specifies the tool's purpose and behavior, similar to the 'Process' example. The minimal length is not justified by clarity or utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with no annotations and no output schema. It doesn't explain the operation's effect, return value, or any side effects. The agent is left to infer everything from the tool name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the lineItemId parameter with the explanation 'Path parameter lineItemId', which gives 100% schema description coverage. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive' is a vague verb that does not specify the resource (line item) or the object being archived. It doesn't clearly distinguish from sibling delete/archive tools, and it's ambiguous whether it means soft-delete or hard-delete. The tool name already conveys more information than the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like batch-archive or other delete operations. No context, prerequisites, or exclusions are mentioned, leaving the agent without any usage framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. 'Archive' gives no information about side effects (e.g., whether the object is permanently deleted, if associations are affected, or if this is reversible). It fails to convey any behavioral traits beyond the bare operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single word 'Archive' does not earn its place because it fails to communicate necessary information. It is not well-structured for an agent's use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete/archive operation with two parameters, no output schema, and no annotations, the description is completely inadequate. It omits the object type and ID semantics, any mention of permanence, effect on existing data, or how it relates to similar archive/delete tools. The user cannot effectively invoke this tool based on the current description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters described as 'Path parameter objectType' and 'Path parameter objectId'. While these descriptions are minimal, they at least label the parameters. The description adds no additional semantic context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive' is extremely vague and does not specify the resource or action clearly. It could refer to archiving any object, and it does not distinguish this from the many sibling archive tools like post-crm-v3-objects-objtype-batch-archive_archive. The tool name suggests delete, but 'Archive' alone is ambiguous and effectively a synonym, not a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use this tool versus alternatives. No context, exclusions, or alternatives are mentioned. The description provides no usable direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. The description says only 'Read', which gives no insight into what the function returns, whether it has side effects, authorization requirements, or any other behavioral traits. This is a severe lack of transparency for a tool whose name suggests a complex API endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word, which is extremely short but not appropriately concise because it omits nearly all necessary information. This is under-specification rather than conciseness. A useful description would include at least the resource and any key details, but this one provides no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex name suggesting a specific CRM v4 endpoint, and the absence of an output schema and annotations, the description is completely inadequate. It does not explain what the endpoint does beyond a generic verb, nor does it mention response format, pagination, or any operational context. The agent cannot infer how to correctly invoke this tool based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters ('Path parameter toObjectType', 'Path parameter fromObjectType'), reaching 100% schema coverage. Since schema coverage is high, the baseline is 3. The description 'Read' adds no additional parameter semantics, but it doesn't contradict or omit information beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Read', which is a verb but does not specify what is being read. The tool name indicates it's about CRM v4 association definitions configurations, but the description alone is too vague to distinguish from other 'get' tools. It fails to communicate the resource being acted upon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or situations where another tool would be more appropriate. The single word 'Read' offers zero contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but 'List' reveals nothing about return format, pagination, required permissions, or side effects. It adds no context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('List') but under-specifies the tool's purpose and behavior. It is not concise in a useful way; it omits critical information, similar to the 'Process' calibration example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description should provide essential context about what the tool does and returns. 'List' is completely inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (objectType is described as 'Path parameter objectType'), which meets the baseline. The description 'List' adds no semantic detail about how the parameter affects the operation, but the parameter is self-explanatory from its name and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List' is a verb but lacks a resource or scope. It does not state what is being listed, and the tool name suggests it lists CRM v4 objects by object type, but the description alone is too vague to distinguish from siblings like get-crm-v4-objects-objtype-objid_objid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools (e.g., v3 object listing, single-object retrieval, batch operations). There is no mention of the objectType parameter or any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a body parameter is required, but does not mention side effects, idempotency, authentication needs, or response behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It does not provide enough information to be useful, and the phrase 'REQUIRES body parameter' is redundant with the schema's required field. It lacks meaningful content despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested schema, no output schema, and complex sibling relationships. The description does not explain return values, required properties semantics, or how this relates to other invoice operations like batch-create or search. Reliance on the schema alone is inadequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% and includes meaningful descriptions for the parameters (e.g., properties key-value pairs and association structure). The description adds no parameter information other than pointing to the schema, which meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Create' which indicates an action but does not state what resource is being created. The name contains 'invoices' but the description itself lacks specificity, making it vague and indistinguishable from other object creation tools like those for quotes or line_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention batch create, upsert, or any context that would help an agent select this over sibling tools. The only note about required body is a requirement, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as side effects, required permissions, or response format. It only mentions the body parameter and schema, omitting all operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. 'Create.' is essentially pointless, and 'REQUIRES body parameter' is redundant. It fails to provide meaningful information, so it's not conciseness but under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects and no output schema, yet the description provides no guidance on how to construct parameters or what to expect. It merely defers to the inputSchema, leaving the agent without critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptions for properties and associations already present in the input schema. The tool description adds no extra parameter semantics beyond pointing to the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply says 'Create' without specifying the resource (quotes) or distinguishing from sibling create tools for other object types. It relies entirely on the tool name for context, so it's barely above a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like batch-create or patch. The description only says 'REQUIRES body parameter' which is a requirement, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states 'Delete' and a requirement for a body parameter. No mention of consequences, idempotency, permissions, or whether the action is destructive beyond the generic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It mentions a critical requirement (body parameter) but omits essential context about the operation, making it more under-specification than concise clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a delete/purge operation with three required parameters and no output schema or annotations. The description fails to explain what is deleted, what the parameters represent, or any side effects, leaving the agent without enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a basic description. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Delete' but fails to specify what resource is being deleted. The tool name suggests association definitions configurations, but the description alone does not convey this. It is not a tautology but is too vague to be useful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling create/update/delete tools. It only says 'Delete' and to check the schema, without specifying the intended use case or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden, but it reveals virtually nothing about behavior. It doesn't say whether the operation is read-only, what the response contains, or any side effects. The only hint is that a body is required, but even its structure is undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but it's under-specified rather than concise. 'Report.' is a fragment that conveys no actionable information. The second sentence is a directive to check the schema, which is not a substitute for explaining what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a report tool with no output schema, no behavioral details, and an opaque body parameter. The description fails to describe what data is returned, how to construct the request body, or why this report differs from other association APIs. It is almost entirely inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (both params have descriptions), the body description 'Request body data (schema not specified in OpenAPI)' is vacuous. The tool description merely tells the user to check the inputSchema, adding no additional meaning. The body parameter's structure and purpose remain completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Report' is extremely vague and mostly restates the tool name's 'report' concept. It doesn't specify what the report does, what resource it acts on, or how it relates to the sibling association tools. The name suggests a usage high-usage report, but the description fails to elaborate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other association report or CRM tools. It only mentions that a body parameter is required, but gives no context about scenarios, prerequisites, or why this tool should be selected over siblings like post-crm-v4-associations-var-var-batch-read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden for behavioral disclosure. It does not state side effects, authorization needs, idempotency, or response behavior, leaving the agent without essential safety or operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, but this is under-specification rather than effective conciseness. It omits necessary information and does not front-load any useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a PUT mutation with 5 required parameters, a nested body object, no output schema, and no annotations, the description is severely incomplete. It fails to explain the purpose, request body, or the effect of the operation, making it nearly useless for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for parameters, though the descriptions are minimal ('Path parameter X'). The tool description itself adds no parameter semantics, so the baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create Default' uses a verb and a vague noun but does not clarify what 'Default' refers to (e.g., a default association). It does not mention associations or objects, making the tool's purpose ambiguous and indistinguishable from sibling tools like batch-associate-default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, contexts, or exclusions. With many sibling tools, the absence of usage guidance is a critical gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a one-word description, there is zero disclosure of behavioral traits. The tool is a read operation, but the description does not mention side effects, return format, authentication needs, rate limits, or any other behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It does not front-load necessary information; it merely states the generic action. A useful description would be at least a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple GET-by-ID operation, but the description fails to communicate what the response contains, whether it returns a full object, or any invocation context. With no output schema or annotations, the description carries the full burden and is clearly inadequate for an agent to understand expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the two parameters, but those descriptions ('Path parameter objectId' and 'Path parameter objectType') are minimal and merely indicate location. The tool description adds no further meaning. Per the rubric, high schema coverage gives a baseline of 3, but the schema descriptions are not substantive; still, the parameter names themselves are somewhat self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read' is a synonym for 'get' and restates the operation implied by the tool name. It fails to specify the resource (CRM object) or the parameters involved, making it essentially a tautology rather than a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools (e.g., delete, patch, batch-create). The description does not mention any context, exclusions, or alternatives, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Update' and gives an example. The example uses 'id' and 'properties', which are not in the input schema, misleading the agent. It does not disclose side effects, permissions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but 'Update.' is pure filler. The example is included but not structured or formatted clearly, and it is inconsistent with the schema. Some brevity is good, but the content is not helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a complex body structure. The description omits the resource being updated, gives a misleading example, and provides no context about the purpose of the update. This is completely inadequate for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so the baseline is 3. However, the description's example contradicts the schema (example uses 'id' and 'properties' while schema requires 'typeId', 'category', 'maxToObjectIds'), adding confusion instead of clarity. It does not explain the path parameters or the meaning of the body fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Update' but does not specify what is being updated. The tool name suggests association definitions configurations, but the description itself gives no resource context. This is vague and fails to distinguish from the sibling create/purge tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling create or purge tools. It does not mention alternatives, prerequisites, or typical scenarios. The only hint is 'Update', which implies modifying existing resources but nothing else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It simply states the action 'Remove an association' without disclosing side effects, irreversibility, authorization requirements, or impact on related data. This gives the agent no additional behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase) and front-loaded, but it is under-specified rather than appropriately concise. It omits critical context such as the resource scope (schema associations) and how the params relate to the operation, making it closer to a placeholder than a helpful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a minimal description that does not explain what objectType and associationIdentifier refer to, whether this is a destructive permanent action, or how it differs from other association-deletion endpoints. Given the complexity of the CRM domain and the number of sibling tools, this is completely inadequate for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. However, the parameter descriptions are trivial ('Path parameter objectType', 'Path parameter associationIdentifier') and add no semantic meaning beyond the property names. The tool description also does not clarify acceptable values or purpose of these parameters, so it does not elevate above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove an association' is essentially a rephrasing of the tool's name (delete-crm-object-schemas...associations). It lacks scope: it does not specify that this removes an association definition from an object schema, nor does it distinguish from several sibling tools that also remove associations (e.g., delete-crm-v3-objects-objtype-objid-associations-var-var-var_var).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or related tools that perform similar operations (e.g., batch archive, record-level association removal). The user is left to infer the purpose from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It says only 'Archive' and does not mention whether this is a soft delete, whether it is reversible, what happens to the invoice, or any side effects. This is completely inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While being extremely concise, the description is under-specified. A single word provides no structured information and fails to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete/archive operation with no annotations and no output schema, the description should at least state that it archives an invoice by ID and indicate the effect. The one-word description is grossly incomplete and does not help an agent understand the tool's behavior or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with one parameter (invoiceId) properly described as a path parameter. The description adds no meaning beyond the schema, but the baseline for high schema coverage is 3, and the parameter is already clearly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just 'Archive', a vague verb with no resource or scope. It does not clearly state that it deletes or archives an invoice by ID, and it is ambiguous relative to the tool's name which suggests a DELETE operation. This lacks the specificity needed to understand 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like the batch archive endpoint or other delete operations. The description provides no context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no behavioral disclosure, the description is completely opaque. It doesn't state whether pagination, filtering, or rate limits apply, nor what the output format is. The phrase 'Read All' is the only behavioral hint, and even that is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, but this is under-specification rather than effective conciseness. It lacks any structure or detail needed for comprehension, similar to 'Process' in the calibration examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool name suggests a specific resource (object library enablement), the description provides no context about the scope of 'All', what is returned, or any associated caveats. Without an output schema, the description should explain the return value, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. Per the guideline, 0 params = baseline 4. The description doesn't need to add parameter meaning, and the schema is already complete with an empty properties object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read All' uses a verb but the resource is unspecified; it doesn't mention 'object library enablement' or any specific entity. It fails to distinguish from sibling tools like get-crm-v3-object-library-enablement-var_var, which reads a single enablement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure, but 'Read' reveals nothing about return format, pagination, permissions, or side effects. It is virtually devoid of behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word, which is under-specification rather than concise. It does not earn its place as a useful description and provides no structured value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations, no output schema, and a one-word description—insufficient for even a simple read endpoint. Missing any mention of what the tool returns, how to use it, or why it differs from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (objectTypeId) described as 'Path parameter objectTypeId'. While the description adds no extra meaning, the schema already documents the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read' merely restates the HTTP verb implied by 'get' in the tool name, offering no specific verb+resource structure. It fails to indicate what is being read (object library enablement?) and does not distinguish this from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'get-crm-v3-object-library-enablement_enablement' or other read operations. The description provides no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It merely says 'List' and does not mention pagination, read-only nature, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word, which is under-specification rather than conciseness. It does not earn its place by conveying useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, yet the description provides no information about pagination behavior, response structure, or how to use it. This is completely inadequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters already have detailed descriptions in the schema (100% coverage), so the description adds nothing beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads only 'List', which is a generic verb that does not specify the resource (invoices) or distinguish from other list-like operations such as search or batch-read. It essentially restates the action implied by the tool name, providing no unique clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like post-crm-v3-objects-invoices-search_search or batch-read. The description contains no context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals nothing about pagination, filtering, archiving behavior, response shape, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single word does not earn its place; it fails to convey anything useful beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no output schema, the description is entirely inadequate. It provides no context about return values, pagination, or how these parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with detailed descriptions, so the schema provides the needed semantics. The description adds no value beyond what the schema already provides, which keeps this at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just 'List', which restates the verb implied by the tool name but does not specify what is being listed. The name itself is descriptive, but the description adds no information about the resource or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when to choose this over search or batch-read siblings, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a one-word description, the tool's behavior is entirely undisclosed. The agent cannot infer that this is a safe read operation, whether it returns archived items by default, or any permissions or side effects. The description adds zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief, it is under-specified rather than concise. A single word 'Read' does not constitute a helpful description; it omits essential information that could be conveyed in a few sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations, no output schema, and a one-word description. For a GET-by-ID operation, the agent needs to know what response format to expect, whether archived records are included by default, and how to handle optional parameters. The description is completely inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all six parameters. The description 'Read' adds no additional meaning beyond the schema. Per the rubric, baseline 3 is appropriate when the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read' is a tautology of the HTTP GET method implied by the tool name. It gives no indication of the specific resource (line items) or the operation's scope, and it fails to distinguish this tool from the many sibling read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention the required lineItemId or any context for when a single-line-item read is appropriate, nor does it reference batch reads or search as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the full burden of behavioral disclosure. The single word 'Read' reveals nothing about return format, error behavior, authentication needs, or side effects, making it completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification, not conciseness. A single word cannot earn its place as a useful description; it provides insufficient information for an agent to understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and an extremely simple tool, the description still fails to provide any contextual completeness. It omits what is returned, any path parameter specifics, and any operation-level details, making it inadequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the parameter descriptions are minimal ('Path parameter objectType' and 'Path parameter objectId'). Per the baseline rule, high schema coverage yields a score of 3, and the description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read' is a generic verb with no resource specified. It fails to indicate that this tool reads a CRM object by type and ID, and it does not distinguish it from sibling read operations like get-crm-v4-objects-objtype-objid_objid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Update', giving no information about effects, partial-update semantics, immutability constraints, permissions, or side effects. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely sparse at only three words. While concise, it is under-specified for the complexity of the tool, providing almost no informational value. This is not efficient conciseness but rather a failure to communicate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 9 parameters, nested objects, no output schema, and no annotations. The description 'Update a schema' is wholly insufficient to understand what the tool does, how the path parameter works, what the payload controls, or what the outcome will be. It is a complex tool with a one-line tautology.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 even though the description adds no parameter context. The schema itself has descriptions for all parameters, some of which are meaningful (e.g., labels, requiredProperties), though others are generic like 'string parameter'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a schema' is a near-tautology that merely restates the action implied by the tool name and HTTP method. It does not specify which schema, what kind of update, or distinguish this from other schema-related tools like get or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no mention of related siblings. It is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosure. It does not mention that this operation modifies an existing line item, whether it is partial or full update, what happens to unspecified fields, or any permission requirements. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, the description is under-specified rather than concise. A single word 'Update' lacks the necessary details to be useful, and the structure provides no front-loaded benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested properties object), no output schema, and no annotations, the description is woefully incomplete. It provides no information on return values, error conditions, or behavior, making it impossible for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (100% coverage), but the tool description adds no additional meaning. The parameter names and schema descriptions are somewhat generic (e.g., 'Key value pairs representing the properties of the object'), yet the description fails to clarify expected format or semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Update', which tautologically restates the verb 'patch' from the tool name without identifying the resource (line items) or any specific action. It fails to distinguish from sibling patch tools (e.g., patch-crm-v3-objects-objtype-objid_objid) and provides no object context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool or how it relates to alternatives. The description offers no context for selecting between this and other PATCH endpoints for different object types, nor any prerequisites or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update a property' reveals nothing about side effects, permissions, partial vs. full update semantics, immutability of fields, or error behavior. This is a complete absence of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word description is under-specified rather than effectively concise. A tool with 12 parameters and no annotations requires more explanation; the brevity sacrifices actionability and leaves the agent without critical context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, this tool demands substantial contextual guidance. The description provides none of it—no return format, required field nuances, usage scenarios, or operational details. It is completely inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline score of 3 applies. The description adds no parameter meaning beyond the schema, but the schema does describe each parameter, even if some descriptions (e.g., 'Path parameter objectType') are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a property' essentially restates the tool name (patch-crm-v3-properties-objtype-var_var) without adding specificity. It doesn't clarify that this updates a property definition or metadata versus updating a property value on a record, making it a tautology rather than an informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get-crm-v3-properties-objtype-var_var or post-crm-v3-properties-objtype_objtype. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only repeats the mutation implied by the verb 'Create' and the schema-required body, without explaining side effects, authentication needs, rate limits, or return format. The description adds no meaningful behavioral context beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two sentences), but this is under-specification rather than conciseness. The first sentence 'Create.' is content-free and wastes an opportunity to convey purpose. Only the second sentence provides any value by directing users to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects, no output schema, and no annotations, so the description should compensate with richer context. It fails to describe what a line item is, how properties should be structured, whether associations are optional, or what the response will look like. The pointer to the schema is helpful but insufficient for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no parameter-level meaning beyond referring to the input schema. The phrase 'Check the inputSchema for required body structure' is a directive but does not explain properties or associations semantics. It meets the baseline because the schema itself is well-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states only 'Create.' without specifying the resource or object type. While the tool name includes 'line_items', the description itself fails to mention what is being created, making it indistinguishable from other post-crm-v3-objects-* tools. The verb 'Create' is tautological with the POST method and provides no differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like batch-create or search. The note 'REQUIRES body parameter with request data' is about parameter requirements, not usage context. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'Archive' hints that this delete operation might be a soft delete rather than a permanent deletion, but it does not explain side effects, reversibility, required permissions, or what happens to associated records. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one word, which is under-specification rather than efficient conciseness. There is no sentence structure, no object mentioned, and no context. The description is so sparse that it does not earn its place as a helpful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations, so the description is the sole source of context. 'Archive' is completely inadequate for an agent to understand the operation, expected input, or result. It fails to build on the tool name and leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with the single parameter quoteId documented as a path parameter. The description adds no additional parameter meaning, but since the schema fully describes the parameter, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is the single word 'Archive', which provides a vague verb but no resource or explicit action. It does not clearly state that this tool deletes/archives a quote, and it fails to distinguish itself from other delete tools for different object types. This is barely more informative than a tautology, as 'archive' is an ambiguous synonym that could be interpreted as soft delete or a noun.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, typical scenarios, or exclusions. The description provides no context for an agent to decide between this and sibling tools like delete-crm-v3-objects-line_items-var_var or post-crm-v3-objects-quotes-batch-archive_archive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Read' at least implies a non-destructive operation, but it does not mention any behavioral aspects such as return format, filtering options, archived records, or associations. The schema hints at these but the description adds no value beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One word 'Read' is extremely concise, but it is under-specification, not effective conciseness. It does not provide enough information to be useful and fails to 'earn its place'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description 'Read' is completely inadequate for an agent to understand what the tool does, what it returns, or how to invoke it correctly. It does not explain the query capabilities, filtering, or response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds nothing about parameters, but per rubric baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is 'Read', which is a generic verb but does not specify the resource or action. It restates the 'get' operation from the tool name without naming quotes or object retrieval. This is vague and fails to distinguish from sibling read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are many sibling get/read tools (e.g., get-crm-v3-objects-quotes_quotes, get-crm-v3-objects-objtype-objid_objid) that could be confused. The description provides zero context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description 'Read All' does not disclose any behavioral traits such as return format, pagination, safety, or side effects. The agent is left completely in the dark about what happens when invoking this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is excessively terse. It is under-specified rather than efficient, providing no structure or meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has no parameters and no output schema, the description fails to state what is read or what the response contains. For a tool that likely returns association definition configurations, this is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to explain. The baseline for 0 parameters is 4, and the description does not need to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read All' identifies an operation ('Read') but not the resource being read. It does not mention associations, definitions, configurations, or any specific object type, so it is vague and does not distinguish this tool from the many sibling get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about scenarios where this tool is appropriate, nor does it mention exclusions or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. Merely saying 'Update' does not communicate whether this is a partial update, how the idProperty parameter behaves, whether the update is idempotent, or what the response looks like. It gives almost no behavioral information beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One word is concise, but it is under-specification rather than effective conciseness. There is no structure, no key information front-loaded, and no explanation of the operation or its requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a PATCH operation with 3 parameters, a nested object, no output schema, and no annotations. The description is a single word, leaving the agent without any context on request formatting, property handling, or expected behavior. It is completely inadequate for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description 'Update' adds no parameter-level meaning, but the schema does describe each parameter (e.g., 'Path parameter invoiceId'). The schema descriptions are terse but sufficient to identify parameter roles, so the tool description's lack of param info does not lower the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update' is a generic verb that does not specify the resource or the action scope. It relies entirely on the tool name 'patch-crm-v3-objects-invoices-var_var' to convey meaning, and it does not distinguish this tool from sibling patch tools like patch-crm-v3-objects-quotes-var_var or patch-crm-v3-objects-line_items-var_var.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or scenarios where another tool (e.g., batch-update or upsert) would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states a generic requirement for a body parameter. It doesn't mention side effects, required permissions, idempotency, response format, or what the created entity represents. 'Create' implies mutation but no further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, not concise. 'Create.' is a fragment, and the remaining sentence points to the schema without adding value. There is no meaningful structure or front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 parameters, no output schema, and no annotations, but the description does not explain the operation's purpose, return value, or context. It is completely inadequate for an agent to select and invoke the tool correctly, especially with many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so the baseline is 3. However, the schema descriptions are tautological ('string parameter') and the tool description adds no extra meaning beyond 'check the inputSchema.' The parameter names (fromObjectType, toObjectType, name, label) provide some semantics, but the description itself contributes nothing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Create.' with no resource or object specified, leaving the agent to infer from the tool name that it creates association labels. It does not distinguish from sibling POST endpoints like post-crm-v4-associations-var-var-batch-create_create or post-crm-v4-objects-objtype-objid-associations-var-var_var. The verb is tautological with the HTTP method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The only additional note, 'REQUIRES body parameter with request data,' addresses request format, not usage context. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys only that the tool is a read operation, but omits details such as return format, pagination, or permissions, which are essential for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At one word, the description is minimal but severely under-specified. Conciseness should not come at the expense of essential information; this is closer to a label than a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with two parameters and no output schema. It does not explain what the tool returns, when it is appropriate to use, or how it relates to the many sibling tools, leaving critical context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters at 100%, but their descriptions are merely 'Path parameter toObjectType' and 'Path parameter fromObjectType', which add little meaning. The description adds no parameter information, but baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only 'Read', which states a verb but no resource or scope. The tool name suggests getting CRM v4 association labels for two object types, but the description does not confirm this or distinguish it from sibling tools like put/post/delete labels operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior, but it only states 'GDPR DELETE' and a requirement for a body parameter. It doesn't disclose that this is likely a hard/permanent deletion, what happens to associated records, or whether the operation is reversible. The example is about matching properties, which hints at a non-standard delete behavior but remains unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence plus an example), which is concise, but the example is extraneous and does not align with the schema parameters. It earns its place poorly because the space is used for misleading information rather than necessary clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description lacks essential context: deletion semantics (permanent vs soft), target identification (objectId vs idProperty vs body properties), expected response/errors, and any special considerations for GDPR. The provided example is not enough to compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description directly conflicts with the input schema. It says 'REQUIRES body parameter with object properties' and shows an example with a properties object, but the schema lists objectType and objectId as required and has no body parameter. This actively misleads an agent about how to invoke the tool, outweighing the high schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'GDPR DELETE' and provides a concrete example, giving some sense of the operation. However, it doesn't explicitly say it deletes a CRM object or clarify the resource, and the example involving company properties is ambiguous. It distinguishes from regular delete only by the 'GDPR' label, not by clear behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other delete endpoints (e.g., delete-crm-v3-objects-objtype-objid_objid or the v4 GDPR delete sibling). It doesn't mention legal or data-erasure contexts, irreversibility, or prerequisite scopes/permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Delete' and requires a body parameter, but doesn't explain that this is a soft-delete/archive (name says archive), whether it's reversible, or what the side effects are. The term 'Delete' may contradict the 'archive' in the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with 'Delete,' but the example is malformed and takes up space while being inaccurate. It's concise but not effectively structured due to the misleading example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch archive of associations with no output schema, the description is incomplete. It doesn't mention the return format, how it differs from object archive tools, or whether the operation applies to associations between specific object types. The minimal text leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, but the description's example is misleading: it shows inputs as [{"id": "123"}] while the schema requires each input to have 'from' and 'to' objects. This actively contradicts the schema, providing incorrect guidance for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete' and 'object IDs to archive,' giving a clear action and an object scope, but it fails to mention this is for associations or that it's a batch archive. This is vague and could be confused with object deletion tools like post-crm-v4-objects-objtype-batch-archive_archive, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't state that this is for associations, nor does it mention when batch-archive is preferred over single-delete or read tools. The example is provided but without any context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the requirement for a body parameter and shows an example, but does not mention whether this is a partial update, what the return value is, or any potential side effects. The example's 'body' wrapper also contradicts the schema's direct 'properties' parameter, which could mislead agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the action and requirement. The example is practical and earns its place, though it is somewhat bulky. Overall, it is concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. It does not explain what the update returns, whether it is partial or full, or any constraints. The bare example leaves out critical behavioral context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 an example showing the structure of properties, which is helpful, but the introduction of a 'body' wrapper not present in the schema creates confusion about the actual parameter structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Update' and provides an example with properties, making it clear the tool updates an object's properties. However, it does not explicitly name the resource or distinguish it from similar tools like batch-update or create, so it lacks specific differentiation beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as batch-update or post (create). No context is provided about prerequisites or when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implies a write operation but does not mention permissions, idempotency, rate limits, or side effects. The example payload contradicts the schema, showing properties objects rather than from/to/type, which is a misleading behavior trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the example is long, irrelevant to associations, and incorrectly shaped. Every sentence should add value; the example does not, making the structure poor despite the small size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. The description fails to explain what an association is, how batch creation works, or what a successful response looks like. The misleading example compounds the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. However, the description's example actively misrepresents the expected inputs, harming rather than adding meaning. It adds no clarification for fromObjectType, toObjectType, or the structure of inputs beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Create a batch of associations' clearly states the verb and resource. However, the example body uses properties like firstname and email, which are not association inputs (schema expects from, to, type). This could mislead an agent about what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as post-crm-v3-associations-var-var-batch-read_read or the v4 batch-create tool. It only states a requirement (body parameter), not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool name ('Get all schemas') without adding any details about pagination, authentication, rate limits, or the nature of the response. It essentially adds no value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at four words, with no wasted words. However, it is under-specified to the point of being terse; it lacks any structural elements like examples, context, or clarifications that would make it genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It fails to explain what schemas are, whether results are paginated, or what the response contains, forcing the agent to infer critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'archived' with a clear description, achieving 100% schema coverage. The description does not repeat or add to this, so the schema carries the semantic weight, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'all schemas', clearly indicating a read operation for the complete set. This distinguishes it from the sibling tool that fetches a single schema by object type, though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling that retrieves a specific schema. The description provides no context about use cases, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, yet it only restates the tool's action. It does not mention PATCH semantics, which fields are updatable, whether groupName can be changed, response format, or side effects. This is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no fluff, but it is under-specified for a tool with four parameters and a mutation operation. It is concise but lacks structure or elaboration; however, it is not as egregiously minimal as a single word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a sparse description, the tool lacks contextual completeness. The schema fully documents parameters, but the description does not explain update behavior, required versus optional fields, or what the response contains, making it inadequate for an agent to confidently invoke this mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter (label, groupName, objectType, displayOrder) providing meaningful descriptions and examples. The tool description adds no extra parameter information, so the schema carries the load; the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Update') and specific resource ('a property group'), distinguishing it from sibling tools that delete/get/create groups or patch individual properties. However, it does not explicitly mention the object type or group name path parameters, though these are clear from the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as creating/deleting a property group or updating a property. There are no stated prerequisites, exclusions, or context about when a PATCH is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply says 'create a new schema' without mentioning irreversibility, permissions, side effects, or consequences. This is a serious gap for a mutation tool of this complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary action. However, the second sentence is a lazy pointer to the input schema, and the overall content is under-specified. It is concise but lacks the substance needed to stand alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, nested objects, and no output schema, this tool requires substantial contextual guidance. The description does not explain how to construct a valid schema, when to use it, or what the response will look like. It is incomplete for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema provides detailed descriptions for all parameters. The description adds no new parameter information beyond pointing to the inputSchema, so it stays at the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new schema,' which is a specific verb+resource. The tool name confirms it is for posting CRM object schemas. However, it does not explicitly differentiate from sibling tools like the association schema creation tool, so it is clear but not fully disambiguated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention alternatives among the many schema-related siblings, nor does it specify contexts where this tool is appropriate. The only instruction about the body parameter is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only shows a request example. It implies a read operation but does not describe response format, pagination, rate limits, or any side effects. The mention of 'REQUIRES body' is helpful but insufficient for an operation without an output schema or safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of one sentence plus an example, and is not overly wordy. However, the example is a run-on JSON-like structure that is not well-formatted or clearly separated, which reduces readability. The structure could be improved by using a code block or clearer labels.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should provide more operational context, such as expected response fields or error conditions. It only covers the request side, leaving the return value and other important behaviors unexplained. This makes the tool incomplete for an agent to correctly interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines fromObjectType, toObjectType, and inputs (each item with id). The description's example adds 'properties' and 'propertiesWithHistory' as top-level body fields, which are not present in the schema, creating a contradiction. While it attempts to illustrate usage, it introduces unsupported parameters that could mislead an agent. The schema coverage is high, but the description's example conflicts with the structured definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a batch of associations,' providing a specific verb and resource. It matches the tool name and gives a concrete example, making the purpose evident. However, it does not explicitly mention the two object types (fromObjectType/toObjectType) involved, which would further distinguish it from other batch-read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives (e.g., single-association reads or batch reads for other object types). The only contextual information is a requirement for a body parameter, which is more about request construction than usage scenarios. There are no exclusions or 'when not to use' notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose critical behavioral aspects: what happens to the secondary object (archived/deleted?), which object's properties take precedence, and whether associations are preserved. The example only shows property fields, not the consequences of merging. The description also incorrectly claims a 'REQUIRES body parameter' without any indication that the tool may be destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the second sentence is poorly structured: the JSON example is cumbersome and the REQUIRES statement conflicts with the schema. The sentence about body parameter could be removed or corrected. Despite this, it is not overly verbose, so it earns a passing score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a merge operation with no output schema and no annotations, the description is incomplete. It doesn't explain the merge semantics, return value, or implications for related records. It also fails to mention the v4 alternative, which is essential for making an informed choice. The example is object-type-specific (companies) and doesn't generalize.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the parameter descriptions are generic ('string parameter'), adding no clarity. The description's example focuses on a 'body' parameter that is not present in the input schema, actively misleading the agent about how to provide the required parameters. It fails to explain the roles of objectIdToMerge and primaryObjectId, which are central to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: 'Merge two objects with same type.' It identifies both the operation (merge) and the resource (CRM objects), and distinguishes it from other sibling tools by specifying it merges objects of the same type. However, it doesn't explain the distinction between v3 and v4 merge tools, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the v4 merge tool or batch operations. The only hint is 'same type,' which is insufficient. There is no mention of prerequisites, exclusions, or which merge tool is appropriate for which scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a 'REQUIRES body parameter' and gives an example, but the example is misleading because it shows an object-record payload (with 'properties' key and name/value pairs) rather than property-definition fields like name, label, and fieldType. No response format, idempotency, or prerequisite behaviors are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a clear purpose, but the example occupies significant space and is inaccurate, so it does not earn its place. It is not overly verbose, yet the misleading content undermines the efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (batch property definition creation), but the description gives no context about response behavior, validation, or the need for existing property groups. It also fails to clarify that this is for property definitions, not object records, which is particularly important given sibling tools for batch-cr eating objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds negative value by referencing a 'body parameter' that is not in the schema and by providing an example that contradicts the schema's expected shape for 'inputs.' It does not explain the required fields for each property (name, label, type, fieldType, groupName) beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a batch of properties,' which clearly identifies the verb (create), resource (properties), and scope (batch). It distinguishes from sibling tools like single-property creation through the word 'batch,' though it does not explicitly mention that these are property definitions rather than object records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as single property creation or batch read/archive. The description does not mention that this endpoint creates property definitions, nor does it exclude using it for object records, which is a significant ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only says 'List association types', which essentially mirrors the tool name and adds no detail about read-only guarantees, auth requirements, pagination, or error handling. It fails to disclose any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence and front-loaded, but it is under-specification rather than genuine conciseness; it lacks necessary detail to be useful beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters, the description is too minimal to fully guide an agent; it doesn't specify what 'association types' means, how the object type parameters are used, or what the response contains. Sibling tools create ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes both parameters as 'Path parameter fromObjectType' and 'Path parameter toObjectType', providing minimal semantic meaning. The description adds no extra parameter context, but with 100% schema coverage the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'List' and resource 'association types', indicating the tool lists association types between two object types. However, it does not distinguish from sibling tools like get-crm-v4-associations-definitions-configurations-all_all, so it's clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; the description is a single phrase with no context about prerequisites, object types, or differences from other association-listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Create an association' and that a body is required, providing no information about side effects, permissions, idempotency, or return values. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary action. However, the second sentence about body requirements is somewhat redundant given the schema's required fields, but it is not wasteful enough to lower the score further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, the description should provide more context, such as permissions, effects, or what the response will be. It only covers the bare minimum and lacks operational context needed for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptions for all four parameters. The description adds little beyond pointing to the schema ('Check the inputSchema'), so it does not enhance parameter understanding, but the schema itself already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create an association' with a clear verb and resource. However, it doesn't distinguish from sibling tools like post-crm-v3-associations-var-var-batch-create_create, which also create associations, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It only instructs to check the inputSchema for body structure, which is parameter-related, not usage context. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior independently. It states the body requirement and provides an example, but the example is incomplete and misleading (shows only 'id' fields, omitting required 'from', 'to', 'type' structure). No mention of effects (e.g., destructive nature), reversibility, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and an example. It front-loads the primary action and requirement without unnecessary verbosity. The example could be formatted better but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It fails to clarify the archive semantics, the complete request structure, or the role of path parameters. The misleading example compounds the gap, leaving an agent under-informed about critical invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal value. The example attempts to illustrate inputs but is structurally incorrect per the schema, and it does not explain the meaning of fromObjectType, toObjectType, or the nested from/to/type fields. This could mislead an agent into sending an invalid payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Archive a batch of associations', identifying the verb (archive), resource (associations), and batch scope. This distinguishes it from sibling tools like batch-create or batch-read for associations. However, the example payload is simplified and inconsistent with the schema, slightly muddying the precise operation but not the overall purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It mentions a requirement ('REQUIRES body parameter') but does not explain when archiving is appropriate, prerequisites, or alternatives. The sibling list includes create/read/archive for associations, but the description does not differentiate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of behavioral disclosure. It states a hard requirement ('REQUIRES body parameter') but does not explain the effects of archiving (e.g., soft delete, reversibility), permissions needed, or any side effects. The only behavioral trait added beyond the schema is the requirement itself, which is already obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, but the included example is technically wrong, which reduces its value. A correct example would be more helpful; as written, it adds confusion rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only a short description, no annotations, no output schema, and a schema with generic param descriptions. The description fails to explain the difference between archiving properties versus objects, the meaning of 'properties' in this context, or any post-archive behavior. The contradictory example further undermines its completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides generic descriptions for both parameters, but the description actively contradicts the schema. It directs the agent to use 'object IDs' and provides an example with 'id': '123', while the schema requires each input item to have a 'name' property (e.g., 'my_custom_property'). This misleading example could cause incorrect invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Archive a batch of properties.' This is a specific verb+resource pair that distinguishes it from sibling object-archive tools. However, it doesn't explicitly mention that these are custom property definitions rather than object records, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when archiving multiple properties) and provides a body example, but it does not offer explicit guidance on alternatives or scenarios where this tool should not be used. No exclusions or comparisons to sibling batch-archive tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It says 'Read' implying a non-destructive operation, but it does not disclose side effects, auth requirements, rate limits, pagination, or response format. The example shows the request shape but adds no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: 'Read' followed by the key requirement and a compact example. Every word earns its place, and the structure front-loads the purpose. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs a batch read of associations, but the description lacks essential context: no output schema, no return value explanation, no mention of how fromObjectType/toObjectType work, and no error handling or pagination details. The example only illustrates the request body, leaving the response and broader usage incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are generic ('string parameter', 'Array of items'), but the example in the description adds some meaning by showing inputs with IDs and properties. However, it introduces 'propertiesWithHistory' which is not present in the schema, potentially confusing users. Overall, the added value is modest given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read' and specifies that a body with object IDs and properties is required, but it doesn't explicitly name the resource (associations) or distinguish itself from sibling batch operations like batch-create or batch-archive. The tool name carries the specificity, but the description alone is vague about what exactly is being read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a requirement ('body parameter with object IDs and properties') but offers no guidance on when to use this tool versus alternatives. It does not mention context, exclusions, or alternatives among the many sibling association tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It reveals only that the operation is a read, but says nothing about what data is returned, the meaning of the 'archived' or 'properties' parameters, error conditions, or any side effects. This is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise ('Read a property') but overly terse. It is front-loaded and has no wasted words, yet it lacks enough substance to be considered well-structured. A brief but useful description would include what kind of property and key context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and a very sparse description. The description does not explain what the tool returns, how parameters like 'archived' and 'properties' affect the result, or the role of objectType and propertyName beyond being path parameters. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description itself adds no parameter semantics; it simply restates the action. The schema provides generic parameter descriptions like 'Path parameter objectType' which are not very helpful, but the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read a property' clearly states a specific verb (read) and resource (property), making it evident that this tool retrieves a single property. However, it does not differentiate among sibling tools like listing all properties or getting property groups, so it doesn't fully distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about scenarios, prerequisites, or relationships to other property-related tools, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It mentions a required body parameter but does not describe output format, pagination behavior, error conditions, or whether it returns a list. The example hints at request structure but offers no insight into response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not optimally structured. It leads with the HTTP method and endpoint, then gives a requirement and an example. The example is useful but inline JSON makes it less scannable. It earns its place but could be clearer if condensed or formatted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficiently complete. It does not explain that the tool returns matching quote objects, that results can be paginated, or how limits apply. An agent would need to inspect sibling tools or make assumptions about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 a concrete example showing how to structure filterGroups and properties, which clarifies parameter usage beyond the schema's individual descriptions. However, it does not compensate for the 0 required parameters discrepancy (description implies body is required while schema marks none as required).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the endpoint as a search operation on quotes ('POST /crm/v3/objects/quotes/search') and provides an example of search criteria, making the core purpose clear. It distinguishes from sibling search tools (e.g., line_items, invoices) by the resource name, though it lacks an explicit verb phrase like 'Search for quotes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this search endpoint versus alternatives like batch-read or individual get. It only states a requirement ('REQUIRES body parameter') without explaining when search is preferable or what distinguishes it from other read operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the action and fails to mention whether this operation replaces existing associations, requires existing objects, or has any side effects. This is a significant transparency gap for a mutation endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. However, it is under-specified for a tool with 6 parameters and complex association semantics, and it restates the tool's name in prose without adding structured information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation with 6 required parameters and no output schema, the description is severely incomplete. It lacks information about expected return values, error conditions, request body format, or prerequisites, making it inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions), but those descriptions are tautological ('Path parameter objectId'). The tool description adds no meaning about parameter relationships or the body structure. Baseline is 3 due to high coverage, though the description does not compensate for the weak schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Associate') and the resource ('an object with another object'), which matches the tool's name. However, it does not distinguish from sibling association tools such as batch-create or delete associations, nor does it specify whether this is a create, update, or replace operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this endpoint versus alternatives like the batch-create or batch-archive association tools. No context, prerequisites, or exclusions are provided, leaving the agent without direction for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the transparency burden. 'Delete a schema' only names the action, without disclosing irreversibility, scope of deletion, required permissions, or side effects on associated data or properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the verb. It wastes no words, though the extreme brevity edges toward under-specification, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive schema deletion with no annotations or output schema, the description provides none of the necessary contextual details—such as reversibility, data impact, permissions, or required state (e.g., archived). It is minimally informative and insufficient for an agent to reason about consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 per the rubric. However, the description itself adds no parameter context; the 'archived' parameter seems semantically odd for a delete (description says 'return results') and the tool description does not clarify its role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and resource 'a schema', clearly indicating the operation. It broadly distinguishes from sibling tools, though it doesn't specify whether it deletes a schema definition versus associations or object instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list contains many delete operations (objects, associations, properties, schema associations), but the description offers no exclusions, prerequisites, or preferred context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Remove' which implies mutation, but does not disclose whether the deletion is reversible, what happens if the association does not exist, permission requirements, or any side effects on related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no extraneous words. It immediately conveys the operation and is optimally concise for such a simple endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This mutation tool has no annotations, no output schema, and only a minimal description. It fails to mention expected responses, error behavior, or any special conditions, so the information provided is not sufficient for an agent to invoke it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all five parameters, and the schema descriptions (e.g., 'Path parameter objectId') are present, giving high coverage. Per the rubric baseline for high coverage is 3; however, the description adds no additional semantic meaning beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove an association between two objects' clearly states the verb and resource. It is specific enough to understand the core action, though it does not explicitly distinguish from similar sibling tools like the v4 delete-association endpoint; that differentiation is left to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, scenarios, or exclusions, leaving the agent without context for choosing this over the v4 association delete or other related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. 'Archive' suggests a soft delete but does not disclose consequences, reversibility, or whether it permanently removes the property definition. It also doesn't mention any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and easy to scan, though terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter delete with no annotations or output schema, the description is under-specified. It doesn't explain the impact of archiving, how it relates to other property operations, or what the response indicates. The agent has no context for usage or trade-offs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides descriptions for both parameters, but they are generic ('Path parameter objectType'). The description doesn't add semantic meaning to the parameters, leaving the agent to infer that objectType and propertyName identify the property to archive. Baseline 3 applies due to full schema coverage, but the descriptions are thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Archive') and resource ('a property'), clearly identifying the action. However, it doesn't explicitly distinguish this singular property archive from sibling batch-archive endpoints, though the singular phrasing implies one property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like the batch archive or v4 delete endpoints. There are no prerequisites, exclusions, or context cues beyond the bare statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description simply says 'Get an existing schema' without describing any side effects, permissions, or response characteristics. It does not explicitly state that the operation is read-only, which would be useful given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short sentence that conveys the core action. There is no unnecessary text or repetition. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is still too minimal. It does not mention what the schema represents, how the objectType parameter affects the result, or what the response might look like. This leaves important context missing for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter 'objectType', but the description of the parameter is minimal ('Path parameter objectType'). The tool description does not add any additional meaning about the parameter. Per the rubric, with high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('an existing schema'). The tool name includes 'v3-schemas-objtype_objtype', which indicates it retrieves a schema by object type, providing additional context. However, the description itself does not explicitly differentiate from the sibling tool that lists all schemas, so it lacks full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with sibling tools. This leaves the agent without explicit direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states 'List associations'. It does not mention response format, pagination, error cases, authentication requirements, or whether both directions of associations are returned. The minimal phrase leaves significant gaps for a GET operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core action and resource. It is front-loaded and contains no unnecessary words, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is under-specified. It does not explain what the list of associations looks like, whether it returns association IDs, labels, or other metadata. There is no mention of pagination or limits. With numerous sibling association tools, this description is insufficient for an agent to understand the tool's full behavior and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each parameter has a 'Path parameter' description), so baseline is 3. The tool description adds little beyond schema: 'by type' loosely maps to toObjectType, but it does not clarify the meaning of objectType vs objectId vs toObjectType. The schema names themselves are mostly self-explanatory, so no additional compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List associations of an object by type' clearly specifies the action (list) and resource (associations of an object), with 'by type' hinting at the toObjectType parameter. It distinguishes from sibling association tools by being the GET/list operation, but could be more explicit about the object and target type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the read operation for associations, nor does it contrast with create/delete/put association tools among the siblings. The need to use it is implied by the verb 'List' but no explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Read a property group' implies a non-destructive operation, but it discloses nothing about authentication requirements, response format, error behavior (e.g., if the group does not exist), or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence, 'Read a property group', which is extremely concise and front-loaded with the verb and resource. It contains no filler or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the description is minimal. It lacks contextual details such as the meaning of a property group, examples of valid objectType values, what the response contains, or any pointers to related operations. For a simple read this is borderline, but given the large sibling set, the description does not provide enough context for confident selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of the two parameters, but the descriptions 'Path parameter groupName' and 'Path parameter objectType' are tautological and uninformative. The tool description adds no semantic meaning about what objectType or groupName represent, so it does not enhance the schema; the baseline of 3 is appropriate given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read a property group' provides a specific verb (read) and resource (property group), clearly indicating a single read operation. However, it does not explicitly distinguish from the sibling list operation 'get-crm-v3-properties-objtype-groups_groups' or mention that it retrieves a group by objectType and groupName, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as listing all property groups, deleting a group, or patching a group. It only states the basic action, leaving the agent to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Read all properties' only states the action; it doesn't disclose return format, pagination, or that it returns property definitions rather than object values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence front-loaded with the verb 'Read'. It is efficient but slightly under-specified for a tool with 3 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with no output schema and no annotations. The description is insufficient: it doesn't mention the required objectType scope, what 'properties' means (property definitions vs object values), or any response details. Given the available sibling tools, more context would help an agent select it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all three parameters (archived, objectType, properties). The tool description adds no additional parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read all properties' clearly identifies the action (read) and resource (all properties), distinguishing it from siblings like get-crm-v3-properties-objtype-var_var which reads a single property. However, it doesn't explicitly state that properties are scoped to a given object type, relying on the tool name and schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't mention when to use this tool vs alternatives like post-crm-v3-properties-objtype_objtype or get-crm-v3-properties-objtype-var_var, nor any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'create' and gives an example, but does not mention return formats, partial success behavior, limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The example is somewhat long but serves a clear purpose. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex batch creation tool with nested associations in the schema, but the description does not mention important context like including associations, response details, or rate limits. The schema covers parameters, but the description adds little operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The example adds some meaning by showing the structure, but it introduces ambiguity by showing a 'body' wrapper that doesn't align with the schema's top-level 'inputs' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a batch of objects') with a specific verb and resource. It differentiates from read/update/archive siblings by explicitly saying 'create', though it doesn't explicitly contrast with batch-upsert or v4 variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like batch-upsert or batch-update. The only guidance is a requirement about the body parameter, not contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states that a body is required and points to the schema, but omits side effects, auth needs, permissions, or response behavior. For a mutation tool this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences. The second sentence about checking the input schema is useful though slightly redundant with the schema itself, but overall it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the tool has 15 parameters, no annotations, and no output schema. The description is too thin for this complexity—it fails to mention the objectType path parameter, that this is a single create, or what the response contains. More context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 thoroughly. The description adds no parameter-specific meaning beyond pointing to the schema, which meets the baseline for good coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a property' clearly states the verb and resource, making the core purpose unambiguous. However, it does not differentiate from sibling tools like the batch-create variant, which is a gap for distinguishing between single vs. batch creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., batch create). It only mentions a body requirement, which is a usage constraint but not a selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must disclose behavioral traits. It only says 'create' without explaining side effects, required permissions, how default associations are applied, or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it contains a slight redundancy by both stating that a body parameter is required and telling the user to check the schema. Still, it is appropriately sized and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a batch mutation tool with no annotations and no output schema. The description provides only a basic purpose and a pointer to the schema, leaving out important context such as return values, error handling, and implications of creating default associations. It is incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of the three required parameters, so the baseline is 3. The description does not add any parameter-level meaning; it merely points to the schema, which already handles the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create Default Associations' which is a clear action and resource, and it's more readable than the tool name. However, it does not differentiate from sibling tools like batch-create or batch-associate, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only notes that a body parameter is required and directs the reader to the schema. There is no information about when to use this tool versus alternatives, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It says 'Delete' but the tool name includes 'archive,' which may imply soft deletion, yet nothing is disclosed about effects, reversibility, permissions, or response. The requirement to send a body is noted but is more about parameters than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat redundant—'REQUIRES body parameter with request data' and 'Check the inputSchema for required body structure' convey overlapping info. It is front-loaded with the purpose, but a single merged sentence would be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and fully explains inputs, but the description omits context about batch semantics, the difference from single-label deletion, and what happens to associations. There is no output schema to clarify returns. For a complex tool, more context would be desirable, but the minimal description is still viable since it points to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond directing the agent to the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete Specific Labels,' identifying the verb (delete) and resource (specific labels). However, it does not mention that this is a batch operation, which could confuse it with the sibling tool delete-crm-v4-associations-var-var-labels-var_var that also deletes a label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only notes that a body parameter is required and tells the agent to check the input schema. It provides no guidance on when to use this tool versus the single-label delete tool or other alternatives, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a body parameter is required and gives an example, but it does not disclose what happens on success (e.g., returns created object ID), any required permissions, idempotency, or error conditions. For a create operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of one imperative verb and a short example. It is front-loaded with the action and includes no unnecessary words or repetition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 3 parameters with nested structures, no annotations, and no output schema, the description is quite incomplete. It does not explain the return value, how to use the 'associations' parameter, or potential failure scenarios. The example only covers companies, leaving other object types under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The tool description adds a concrete example for companies, showing how to structure the 'properties' parameter and specifying required fields like 'name', 'domain', and 'industry'. This adds meaning beyond the generic schema descriptions, making the parameter semantics clearer, even though it doesn't cover all object types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create,' which is a clear verb, and provides an example for companies with properties. However, it doesn't explicitly name the resource being created (e.g., 'CRM object') and does not distinguish this from sibling tools like the batch create endpoint. The example gives some hint, but the purpose is vaguely stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as batch create, update, or search endpoints. The description implies usage by requiring a body parameter, but it does not mention when this single-create tool is appropriate or when to prefer a different tool. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It only says 'Update' and gives an example, but does not disclose whether this is a partial merge or full replacement, what happens on missing fields, authentication needs, or idempotency. The 'body' wrapper in the example may also confuse parameter mapping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short pieces: verb, requirement, example. It's compact and front-loaded with 'Update.' The example earns its place but could be formatted better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and minimal description. It doesn't explain return values, error cases, or the role of objectType/objectId. For a core update operation, it's incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions, so baseline is 3. The description adds an example showing the body structure with 'properties' inside 'body,' but this example uses a 'body' key not present in the schema's top-level parameters, potentially confusing rather than clarifying. Still, it reinforces the format of properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update,' a clear verb, and the example shows updating properties like firstname and email. The tool name and schema confirm it patches a CRM object, but it does not distinguish from sibling patch-crm-v3 tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'REQUIRES body parameter with properties to update,' giving a usage prerequisite. However, it offers no guidance on when to choose this tool over other update tools like post-crm-v4-objects-objtype-batch-update or patch-crm-v3, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the body parameter requirement but does not disclose that merging typically deletes or modifies the source object, nor any data-loss implications. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus an example, front-loaded with the core action. No filler, though the body/schema mismatch slightly detracts from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist. The description omits essential context like the fate of the merged object, return behavior, and the correct placement of parameters (body vs top-level). The discrepancy between the documented 'body' and schema parameters makes the tool incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are generic ('string parameter'), but the example clarifies the roles of objectIdToMerge and primaryObjectId. However, it also introduces a 'body' parameter not reflected in the schema, which confuses rather than clarifies. Baseline 3 applies since schema coverage is nominally 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Merge two objects with same type' which clearly identifies the verb and resource. However, it does not differentiate from the sibling v3 merge tool (post-crm-v3-objects-objtype-merge_merge), so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit requirement ('REQUIRES body parameter with merge details') and an example, giving some usage guidance. However, it lacks any mention of when to prefer this tool over alternatives or any exclusion criteria, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool creates or updates in batch, but does not mention important behavioral aspects such as idempotency, partial failure behavior, required permissions, rate limits, or what happens with conflicting unique property values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The second sentence about checking the schema is somewhat redundant but conveys that the body is required. Overall it is concise with no significant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations and no output schema, the description is incomplete. It fails to explain return values, error conditions, or how the upsert behaves when multiple items match the same unique property. The schema covers inputs well, but the description alone is insufficient for agents to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'inputs' is fully described in the schema. The description adds no new parameter semantics beyond telling the user to 'Check the inputSchema for required body structure,' which is redundant given the schema is already available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Create or update a batch of line items by unique property values.' This specifies the verb (create/update), the resource (line items), and the distinguishing mechanism (unique property values), which differentiates it from sibling batch-create and batch-update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like batch-create or batch-update. The only instruction is that a body parameter is required and to check the input schema, which does not help the agent choose between the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It notes that a body parameter is required, which is a key invocation requirement, but it fails to disclose whether the operation is read-only, what the response shape is, or any pagination/limiting behavior (despite these being in the schema). The example provides some structural insight but not behavioral expectations beyond the request format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the endpoint and requirement, followed by a useful example. The example is slightly verbose but directly aids usage. There is no filler or repetition of every schema detail. It earns its place by clarifying the required body structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient to initiate a search call with the provided example, but it lacks important context such as the response format (no output schema provided) and any notes on pagination or property selection beyond the schema. Given the absence of annotations, the description only partially compensates for missing structured context, leaving the agent to infer return values and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so the baseline is 3. The description adds significant value by specifying that parameters must be wrapped in a `body` object (e.g., `{body: {...}}`), which is not apparent from the schema's flat properties. It also gives a concrete example showing how to compose filterGroups and properties, clarifying the intended use of these parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as a POST to the line_items search endpoint and clarifies that it requires a body with search criteria. It clearly refers to searching line items, which distinguishes it from search endpoints for other object types (quotes, invoices) among the siblings. However, it does not explicitly state 'search line items' in prose, relying on the endpoint path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete example of how to structure the body, which implies usage for searching with filterGroups and properties. But it gives no explicit guidance on when to use this tool versus alternatives like batch-read or get endpoints, nor any exclusions or recommended scenarios. The example is the only usage signal, but 'when' context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the create/update nature and batch processing, but lacks important behavioral details such as idempotency, what happens if no matching unique property is found, error handling, or whether the operation is atomic. The 'REQUIRES body parameter' statement is also misleading relative to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose front-loaded in the first sentence. The second sentence about the body parameter is somewhat vague and potentially redundant given the schema, but overall the text is short and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch upsert operation with no output schema and no annotations, the description is incomplete. It does not explain what the response contains, how errors are handled, or clarify the unique property matching mechanism (e.g., whether idProperty is required). This leaves significant gaps for an agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal semantic value beyond telling the user to check the input schema; it does not explain how 'unique property values' map to the idProperty or id fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create or update) and the resource (batch of objects), and distinguishes from siblings by specifying 'unique property values'. However, the mention of 'REQUIRES body parameter' is confusing because the input schema shows objectType and inputs as separate parameters, not a single body parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by unique property values' implies the use case of matching on unique properties, but the description does not explicitly compare to alternatives like batch-create or batch-update, nor does it state when not to use this tool. No exclusionary or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It only states 'Create' and the body requirement, without mentioning authentication, property validation, idempotency, response format, or error behavior. The example hints at the expected structure but does not disclose side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with 'Create,' and includes a compact illustrative example. Every clause contributes value, and there is no padding or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested associations parameter, no output schema, and no annotations, the description is not complete enough for an agent to fully understand invocation. It does not explain valid objectType values, association structure, return values, or failure modes, and it lacks usage context relative to the many sibling create/batch tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters (coverage 100%), but the descriptions are generic. The tool description adds a concrete company example with property names and values, which meaningfully supplements the schema's generic 'Key-value pairs' text. It does not add detail for the associations parameter, but the example provides practical value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create' and provides a concrete example for companies with properties, making it clear that this endpoint creates a single CRM object of a specified type. However, it does not explicitly distinguish itself from the sibling batch-create tools, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like post-crm-v3-objects-objtype-batch-create_create or v4 equivalents. The only instruction is 'REQUIRES body parameter with object properties,' which is a parameter constraint, not a decision guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create a batch of objects' and shows an example; it does not mention batch size limits, partial failure behavior, validation rules, authentication requirements, or whether the operation is destructive/irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus an inline example. It front-loads the core purpose and gives a concrete usage pattern without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with moderate complexity and no output schema, the description provides a minimal viable invocation example but lacks important contextual details such as maximum batch size, error handling, and response format. The schema covers structure, but the description does not enrich the context further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema documentation coverage is 100%, so the baseline is 3. The description adds a useful JSON example showing the nested structure for 'properties', but it introduces a 'body' wrapper not present in the schema (which expects 'inputs' directly), creating slight ambiguity. The example clarifies the shape but does not significantly extend beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a batch of objects') and provides a concrete example, making the tool's primary function immediately understandable. However, it does not differentiate this create operation from sibling batch operations like update or upsert, relying on the tool name for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a required body parameter and provides an example, but gives no guidance on when to use this tool versus the many alternatives (e.g., batch-upsert, batch-update). There are no explicit exclusions or conditions for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies the operation as a batch update but does not disclose side effects beyond mutation, partial failure behavior, permissions, rate limits, or response format. The 'REQUIRES body parameter' note is an input requirement, not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action, and the example is illustrative. The text is efficient, but the example's inaccurate body wrapper and missing objectType undermine the structural clarity, preventing it from being a high-quality concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a batch mutation tool with no annotations and no output schema, yet the description does not clarify the full request shape, expected return value, error handling, or partial-failure semantics. It also omits the required objectType from the example, leaving significant gaps for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 useful meaning for 'id' vs 'idProperty' with 'by internal ID, or unique property values.' However, the example '{body: {inputs: [...]}}' introduces a 'body' wrapper that is not part of the schema and omits the required 'objectType' parameter, which is actively misleading about how to supply parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Update a batch of objects') and the distinguishing scope ('by internal ID, or unique property values'). It differentiates this from sibling batch-create, batch-read, batch-archive, and batch-upsert tools, though it doesn't explicitly contrast v3 vs v4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit requirement ('REQUIRES body parameter with objects to update') and a usage example, which gives some implementation guidance. However, it does not state when to prefer this over alternative tools like the v3 batch-update, single-object patch, or batch-upsert, so the when-to-use guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility, but it only states a requirement and gives an example. It doesn't disclose the consequences of the deletion (e.g., irreversibility), required permissions, or response format. 'GDPR DELETE' implies erasure but not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with 'GDPR DELETE', followed by the essential body requirement and an illustrative example. It's concise, though the JSON example could be streamlined without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex CRM operation with legal implications, the description is too sparse. It doesn't explain how the body interacts with objectId, whether this endpoint requires special scopes, what the response looks like, or error cases. The absence of an output schema further increases the need for a richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are generic ('string parameter', 'Path parameter objectType'), and the description adds a body example not present in the schema. This adds value but also creates confusion because the schema requires objectType and objectId, while the description says body is required. The example properties are helpful, but the relationship between body and schema params is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'GDPR DELETE', clearly identifying the operation as a deletion for GDPR compliance. The example with 'companies' and object properties distinguishes it from the sibling standard delete by ID. However, it doesn't fully explain what GDPR deletion entails beyond the label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for GDPR-related deletion and shows that object properties are required in the body, which differentiates it from ID-based delete tools. Yet there is no explicit statement of when to choose this over alternatives or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Read' and does not disclose response format, pagination, error behavior, or whether archived groups are included. The read-only nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain return values and clarify that 'all property groups' refers to groups for the required objectType, not all groups globally. The current description is too sparse to be fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single required parameter 'objectType' with 100% coverage, so the baseline is 3. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('property groups'), with 'all' indicating breadth. This distinguishes it from sibling tools like get-crm-v3-properties-objtype-groups-var_var, which fetches a single group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description does not mention the single-group sibling or any exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only says 'Create' and mentions a 'body parameter' that conflicts with the schema (which expects 'inputs' directly). The example uses a 'body' wrapper, creating confusion. No side effects, permissions, or return details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The example is somewhat verbose but necessary to illustrate structure. The 'REQUIRES body parameter' phrasing is awkward but not overly wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch-create tool supporting properties and associations, the description omits guidance on associations, required fields, response format, or error handling. With no output schema or annotations, this is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the descriptions are generic. The example adds property names but wraps them in a 'body' object not present in the schema, misleading agents about the expected input structure. This negative addition outweighs the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a batch of quotes,' clearly specifying the verb, resource, and batch scope. This distinguishes it from siblings like batch-read, batch-archive, and single-create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'batch' implies us for creating multiple quotes at once, but there is no explicit guidance on when to use this vs alternatives like single create or batch upsert. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Archive a property group' without disclosing side effects (e.g., what happens to properties in the group), reversibility, or permission requirements. The term 'archive' implies a softer action than 'delete' but this is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence, extremely concise and front-loaded with the action verb. It wastes no words and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple delete operation with only two path parameters and no output schema. The description is adequate but lacks context about which object types are valid, the difference between archiving and deleting, and any consequences, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters as 'Path parameter' with their names, providing 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Archive') and specific resource ('property group'), distinguishing it from sibling tools that target individual properties or objects. The purpose is immediately understandable and matches the tool's name and resource path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as archiving individual properties or using batch archive operations. It only states the action without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only notes that a body parameter is required and points to the schema, but fails to mention mutation side effects, idempotency, error behavior, or authentication needs. This is a significant gap for a batch write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and gets to the core purpose quickly. However, the 'REQUIRES body parameter' sentence is somewhat redundant and the all-caps style adds minimal value, so it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex batch upsert tool with no output schema and no annotations, the description is too thin. It does not explain return values, the role of idProperty, partial failure behavior, or provide context beyond the schema. An agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a description, so the baseline is 3. The description adds no semantic details beyond what the schema provides and merely redirects to the inputSchema, which does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create or update a batch of objects') and the distinguishing mechanism ('by unique property values'), which sets it apart from sibling batch-create and batch-update tools. This gives an agent enough to recognize an upsert operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by unique property values' implies when to use this tool (upsert scenarios), but there is no explicit guidance about when not to use it or which sibling alternative to choose. The description provides implied usage context but lacks clear exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Create a batch of invoices', which implies mutation, but does not mention response format, failure behavior, idempotency, or limits. Additionally, the example uses 'body' while the input schema requires 'inputs', creating confusion about the expected parameter structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the purpose front-loaded and an example that aids understanding. However, the example is somewhat verbose and the 'body' wrapper adds unnecessary complexity, so it is not perfectly streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch create operation with no output schema and no annotations, the description should provide more context about return values, batch size limits, partial failure handling, or required invoice-specific fields. It only offers a generic example, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The example provides a concrete shape for the inputs array, which adds value, but it may be misleading by wrapping in a 'body' object that is not present in the schema. It does not clarify nested parameters like associations or objectWriteTraceId beyond their schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a batch of invoices', identifying the specific verb (create), resource (invoices), and scope (batch). This distinguishes it from sibling tools like batch update, upsert, or archive operations, especially given the 'invoices' object type in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example and a requirement that a body parameter is needed, but does not explicitly state when to use this tool over alternatives like batch update or upsert. Usage is implied by the verb 'create' and the batch context, but no exclusions or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the required body parameter and provides a concrete example, but does not explicitly state that this is a read-only search operation, nor does it mention pagination, sorting, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences: the endpoint and an example. The example is somewhat long but serves a clear illustrative purpose. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search API with no output schema and no annotations, the description only covers filterGroups and properties via example, leaving query strings, sorting, and pagination behavior unexplained. While the schema covers these parameters, the description adds little contextual guidance beyond the example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter descriptions, so baseline is 3. The description adds crucial context by requiring a body parameter and providing a concrete example of filterGroups, properties, and operators, which helps clarify how parameters combine in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a POST search endpoint for CRM objects with a path parameter objectType, and the example demonstrates its function. However, it does not explicitly differentiate it from sibling search endpoints for specific object types (e.g., quotes, invoices, line_items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example of how to construct the search body but provides no guidance on when to use this generic search tool versus the object-type-specific search endpoints. It does not mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'REQUIRES body parameter' but does not disclose behavioral traits such as side effects, permission requirements, error behavior, or response details. For a mutating POST operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with two short sentences. It is front-loaded with the core purpose. The last two clauses ('REQUIRES body parameter' and 'Check the inputSchema') are slightly redundant but not verbose. Overall, it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at what the response contains (e.g., the created property group) but does not. It also lacks any mention of prerequisite conditions, such as needing an existing object type. For a simple create tool with 4 parameters, the description is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no extra meaning beyond the schema; it merely instructs to check the inputSchema. The schema itself provides descriptions for all parameters, including examples and usage notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a property group,' using a specific verb and resource. This distinguishes it from sibling tools like post-crm-v3-properties-objtype_objtype (which creates a property) and GET groups endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for the tool ('Create a property group') and notes a key requirement (body parameter). However, it does not explicitly state when to use this tool versus alternatives, such as when to create a property instead of a group, or when to use batch creation. Usage is implied from the purpose and name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only mentions the requirement for a body parameter and provides an example. It does not explain what happens on partial failures, whether the operation is atomic, or what the response contains. This is a significant gap for a batch write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with a practical example, no redundant information, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool, the description omits key contextual information such as response format, error handling, batching limits, and whether partial success is possible. The schema descriptions for nested objects are incomplete (recursion limit reached), so the description should have compensated, but it relies on a minimal example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, so the baseline is 3. The description adds a concrete example showing the structure of the 'body' and 'inputs' parameters, which is helpful. However, the example uses contact-like properties (firstname, lastname, email) which may not match actual line item property names, and it does not clarify the associations or objectWriteTraceId fields beyond the schema's limited descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a batch of line items', specifying the verb and resource, and the example further clarifies the expected input format. This distinguishes it from sibling tools like batch-read, batch-update, and single line item create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description confirms this is for batch creation and requires a body parameter, it does not explicitly contrast this with the single-create endpoint or mention when to prefer batch over single operations. There is no guidance on exclusions or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the create-or-update behavior and the unique-property matching logic, but omits important details like partial failure handling, idempotency, and response format. It adds some context beyond a bare tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is front-loaded with the purpose and remains concise. However, the second sentence 'REQUIRES body parameter with request data' is slightly redundant and imprecise, since the schema calls the required field 'inputs' rather than 'body'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a batch operation with no output schema, the description fails to explain return values, per-item error behavior, or the exact matching semantics for unique properties. Agents would need to make assumptions about how partial successes or failures are reported, which is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive text for all fields, so the baseline is 3. The description adds little beyond pointing to the inputSchema; the 'unique property values' hint aligns with the idProperty field but does not enhance schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or update a batch of invoices') and the mechanism ('by unique property values'), which distinguishes it from batch-create and batch-update siblings that operate purely on IDs. The verb, resource, and condition are all specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by unique property values' implies when to use this tool (when you have unique properties rather than IDs), but it does not explicitly state when not to use it or provide alternatives like batch-create or batch-update. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only notes that a body parameter is required and gives an example, but does not disclose the effects of archiving (e.g., reversibility, permissions needed), response format, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and includes a compact example with no wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, and the description covers the required payload and example. However, it omits behavioral details such as what 'archive' entails, batch size limits, or error handling, leaving some gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides generic descriptions like 'Array of items' and 'string parameter', which are not meaningful. The description adds a concrete example showing the expected structure with object IDs, significantly improving clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool archives a batch of line items by ID, providing a specific verb and resource. It also distinguishes from sibling tools like batch-read or batch-create with the concrete example showing the payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as the single-object delete or batch operations for other object types. No exclusions or prerequisites are mentioned beyond the required body parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic create/update action and a requirement for a body parameter, but does not reveal important behaviors like idempotency, partial failure handling, permissions, or return values. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and is front-loaded with the core verb. The second sentence about the body parameter is somewhat redundant given the schema's required field, but it is brief and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex batch upsert tool with a nested array structure and no output schema. The description lacks essential context such as return values, error behavior, how unique property matching works, and whether the operation is atomic. It is under-specified for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters including inputs, id, properties, idProperty, and objectWriteTraceId. The description adds no new parameter-level semantics, merely directing the user to 'Check the inputSchema.' This meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Create or update a batch of quotes by unique property values.' This distinguishes it from batch-create or batch-update tools for quotes, as upsert behavior is explicitly stated. The verb+resource+mechanism makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case (upserting quotes based on unique property values) but does not explicitly mention when not to use it or suggest alternative tools. It provides enough context to infer usage, but lacks explicit exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature via 'Read' and the required request body structure. However, it does not address authentication needs, batch size limits, error handling, or the response format—key behavioral aspects an agent would need to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and an illustrative example. It front-loads the purpose and includes only necessary details about the required body structure. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should explain return values and edge cases, but it does not. The example covers a common batch read, but omits response format, `idProperty` usage details, and behavior when IDs are invalid or properties are not found. This is a significant gap for complete agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are generic and partially misleading (e.g., properties described as 'Key-value pairs for setting properties for the new object'). The description clarifies that `properties` are 'properties to retrieve' and provides a JSON example mapping `inputs`, `properties`, and `propertiesWithHistory`, adding significant meaning beyond the schema. It does not fully explain `idProperty`, but the overall clarification is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read a batch of objects by internal ID, or unique property values.' This specifies the verb, resource, and retrieval modes. However, it does not explicitly distinguish this tool from sibling batch-read tools (e.g., v3 objects, associations) beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context by noting 'REQUIRES body parameter' and including a concrete example. The word 'batch' implies use for multiple objects, but there is no explicit guidance on when to choose this tool over single-object get endpoints or other batch-read variants, nor are there exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds context with a concrete example and a requirement, but does not disclose whether the operation is read-only, response format, pagination behavior, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, includes the essential endpoint and a compact example, and is well-structured for quick scanning without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is detailed, and the description provides an example, but there is no output schema and the description does not explicitly describe response structure or pagination, leaving some gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 an example demonstrating the structure of filterGroups and properties, providing practical semantics beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the HTTP method and endpoint, identifies the resource (invoices) and action (search), and provides an example. It clearly distinguishes from sibling search tools through the path segment 'invoices'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a requirement ('REQUIRES body parameter with search criteria') and demonstrates usage with an example, but does not explicitly state when to prefer this over batch read or other search operations. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects of archiving (e.g., reversibility, effect on associations). It only gives an example and a requirement, leaving behavioral consequences unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary action. The example is useful, though the wording 'REQUIRES body parameter' is somewhat awkward. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description covers invocation basics but omits response format, error behavior, and what 'archive' semantically implies (e.g., vs delete or restore). Adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are generic ('Array of items', 'string parameter'), so the example adds concrete structure for inputs. However, it doesn't clarify objectType usage, batch size limits, or error handling, and the phrase 'body parameter' is slightly ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Archive'), the resource ('batch of objects'), and the scope ('by ID'). Distinct from siblings like delete and batch-read; unambiguous verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context: when you need to archive multiple objects by ID. However, no explicit alternatives or exclusions are mentioned, nor comparisons to similar v4 endpoints or single-object delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds the requirement for a body parameter and shows a concrete example of the input shape, plus the ability to update by internal ID or unique property values. However, it does not disclose partial-failure behavior, whether the batch is atomic, response format, or permission requirements—important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences and one inline JSON example. It front-loads the primary action and then provides a concrete usage example. Every sentence earns its place, and the example is directly useful for invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations and no output schema, the description is minimally adequate: it identifies the operation, required body, and example. But it omits the required objectType path parameter (only visible in schema), ignores failure/partial-success semantics, and does not explain the response. It also lacks any guidance on choosing between v3/v4 or object-type-specific batch update siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining updatable objects can be identified by 'internal ID, or unique property values,' which maps to the id/idProperty fields in the schema. The example illustrates how to structure the inputs array with id and properties, going slightly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update a batch of objects by internal ID, or unique property values.' It specifies the resource (batch of objects) and the two addressing modes, which helps distinguish from single-object update or batch create/read/archive siblings. However, it does not explicitly differentiate from the many similar batch-update endpoints for specific object types (e.g., quotes, invoices) or the v4 variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch updates and explicitly says 'REQUIRES body parameter with objects to update,' giving a task-level requirement. But it does not state when to prefer this tool over alternatives like single-object PATCH, batch upsert, or batch create, nor does it mention exclusions such as when idProperty is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'update' and provides an example, but does not disclose response behavior, error handling, idempotency, or side effects. The example shows request shape but not what happens after the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus an example, with the purpose stated up front. No filler or repetition; every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is minimal. It fails to mention what the response contains, potential errors, batch size limits, or whether the update is partial. The example helps but does not fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds a concrete example ({body: {inputs: [...]}}) that clarifies the nested structure, and mentions 'unique property values' which aligns with the idProperty schema documentation, adding practical value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a batch of quotes by internal ID, or unique property values', identifying a specific verb (update), resource (quotes), and batch scope. This distinguishes it from sibling tools like batch-read, batch-create, and batch-archive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when updating multiple existing quotes, but does not explicitly contrast with batch-upsert or single-update alternatives. The phrase 'REQUIRES body parameter' is a request format requirement, not guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Read' but does not explicitly confirm read-only behavior, auth requirements, rate limits, or response format. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus an example. The purpose is front-loaded, and the example is directly useful without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the 'what' and 'how' with an example, but omits return value details, error behavior, batch size limits, and interaction with the 'archived' parameter. Given there is no output schema and no annotations, these omissions leave the description incomplete for a production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers all parameters (100% coverage), the description adds a concrete request-body example showing how to structure inputs, properties, and propertiesWithHistory. It also hints at idProperty via 'unique property values', adding practical value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a batch of invoices by internal ID, or unique property values' – a specific verb, resource, and method. It distinguishes from sibling batch-read tools by specifying the 'invoices' object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have known invoice IDs, but it does not explicitly mention alternatives (e.g., search vs. batch-read) or exclusions. There is no when/when-not guidance beyond the implied batch context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavior. It mentions updating by ID or unique property and requires a body, but it does not explain permissions, idempotency, response behavior, or error handling. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a focused example. Every part serves a purpose, and it is front-loaded with the core update functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and the example clarifies the input structure, but the absence of an output schema means the return value or error behavior is unstated. This leaves gaps for an agent needing to interpret the result of the update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for all parameters, so a baseline of 3 is appropriate. The description adds an example of the body wrapper and inputs array, but this is supplementary rather than essential beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a batch of line items by internal ID, or unique property values', specifying the verb, resource, and scope. This distinguishes it from sibling batch-create and batch-archive tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a required body parameter and an example, making the usage context obvious for batch updates. However, it does not explicitly mention alternatives or when-not-to-use scenarios, though the name and description imply the correct context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it does not explain what 'archive' entails (e.g., reversible, soft-delete, permanent), nor does it mention success/failure/partial failure behavior for batch operations. The only additional context is the required body parameter, which is already evident from the schema. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus an example. It front-loads the core action first, then gives a usage example. No filler or redundant information, despite the example somewhat duplicating schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with a clear schema and example, the description is adequate but leaves gaps. It does not describe return values, error handling, or nuances of batch archiving (e.g., partial success). Given no output schema and no annotations, more context would be beneficial, especially since this is a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by providing a concrete example showing the exact request body structure ({body: {inputs: [...]}}), which clarifies how the 'inputs' parameter should be wrapped. This goes beyond the schema's generic 'Array of items' description and aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Archive a batch of quotes by ID.' It identifies the specific resource (quotes) and scope (batch), distinguishing it from sibling tools like the generic batch-archive or single-delete tools. The verb 'archive' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for archiving multiple quotes by ID, but does not explicitly state when to prefer this over alternatives (e.g., single delete or the generic objtype batch-archive). No exclusions or alternative tool references are given, so the guidance is only implied by the tool name and wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'Archive' and the body requirement, but does not mention effects (e.g., whether archiving is reversible), permission requirements, or what happens to the objects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an illustrative example. It is front-loaded with the primary action and immediately gives a practical example. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity, the description covers the core action and input format. However, it omits any information about the response or potential errors, and since there is no output schema, some description of return values would be helpful. Overall, it is minimally viable but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The description adds value by showing an exact example of the inputs structure ({id: '123'}), which clarifies the expected format beyond the generic schema descriptions. It also emphasizes the requirement for the body parameter, adding semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Archive a batch of objects by ID', which uses a specific verb and resource. It distinguishes itself from sibling tools like batch-read, batch-create, and batch-update by explicitly mentioning archive and the batch nature. The example further clarifies the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete example of the required body format, which is a useful usage hint. However, it does not explicitly state when to use this tool versus alternatives (e.g., deleting objects) or mention any exclusions. The context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the core action and provides an example input. It fails to disclose the consequences of archiving (e.g., reversibility, visibility changes), required permissions, or what the API returns—leaving the agent without safety or side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus an example. It is front-loaded with the main purpose and efficiently adds the required parameter detail and usage example without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation and the complete schema coverage, the description is minimally viable—it covers the action and input. However, with no output schema and no annotation, it omits return values, error handling, and behavioral effects, which are useful for an agent to fully understand the tool's outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'inputs' array with 'id' strings, but the description adds clarifying context by explaining that the body must contain object IDs and gives a concrete JSON example. This goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Archive a batch of invoices by ID' with a specific verb and resource, clearly distinguishing it from sibling tools like delete or read operations. The batch and invoices scoping is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context that this is for batch archiving of invoices by ID, which implies when to use it. However, it does not explicitly mention when not to use it or alternatives, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool updates invoices and requires a body parameter, but does not mention batch behavior (e.g., atomic vs partial success), error handling, response format, or prerequisites. This is insufficient for a batch mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence followed by a practical example. It is front-loaded with the action and resource, and contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a clear purpose and example, and the schema covers all parameters. However, with no output schema and no annotations, it lacks details on return values, error handling, or batch update semantics. It is minimally adequate for basic invocation but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description adds a concrete example showing the structure of the inputs array and how to update a property, which helps the agent construct the call correctly. This example clarifies the nested object format beyond the schema listings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a batch of invoices by internal ID, or unique property values,' which identifies the specific verb (Update), resource (batch of invoices), and method of targeting. This distinguishes it from sibling tools that create, archive, or upsert invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to update multiple invoices in a batch. It also specifies the required body parameter with an example. However, it does not explicitly mention when not to use it or alternatives like single-update endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Read' implies non-destructive behavior, and the example clarifies request format. However, it does not disclose response structure, pagination, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, followed by a clear requirement and a concrete example. Every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives sufficient information to invoke the tool in the basic case, but with no output schema it omits return value details. It also does not explain when to use idProperty or how to request history, leaving some gaps for non-standard usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage), but many are generic. The description's example provides concrete values and structure, adding meaning beyond the schema, though it does not explain idProperty or propertiesWithHistory distinctions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a batch of objects by internal ID or unique property values, using a specific verb and resource. It distinguishes from single-object reads and other batch reads by emphasizing 'batch' and including a concrete example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (batch read) and explicitly requires a body parameter, but it does not contrast with alternatives like single-object retrieval or search endpoints. No exclusions or alternate tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the requirement for a body parameter and provides an example, but does not explain behavior for invalid IDs, archived items, or authentication. The word 'Read' signals non-destructive intent, but additional context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a helpful example, with no filler. It front-loads the core purpose and then specifies the required body format, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch-read tool with 5 parameters and no output schema, the description covers the essential purpose, required body, and an example. Optional parameters (archived, idProperty) are not mentioned, but the schema covers them. The tool is clearly distinguished from siblings, though it lacks detail on response format or error handling, resulting in a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. The description clarifies that inputs are object IDs and properties are the fields to retrieve, and provides an example showing propertiesWithHistory as an empty array. This adds value beyond the schema's generic descriptions (e.g., 'Array of items') and earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a batch of line items by internal ID, or unique property values', specifying the verb, resource, and two retrieval modes. This distinguishes it from sibling read/search tools for other object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have known internal IDs or unique property values to retrieve in bulk. It does not explicitly mention alternatives like search or single-read endpoints, but the context is clear and gives a strong signal for when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does this by highlighting the mandatory body parameter and giving a concrete example, which is valuable. It does not detail response format or idProperty usage, but the verb 'Read' implies a safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences and an example. It is front-loaded with purpose and immediately gives actionable invocation guidance without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is fairly complete with the example and mandatory body note. The lack of output schema means return format is not described, but this is a minor gap for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are generic and even misleading (e.g., properties described as 'setting properties'), but the description adds meaning by explaining that inputs contain object IDs and properties are fields to retrieve. The example clarifies the structure beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a batch of quotes by internal ID or unique property values. This specific verb+resource+method distinguishes it from siblings like batch create/update/archive and single quote read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use: reading multiple quotes by IDs or unique properties. However, it does not explicitly name alternatives (e.g., search) 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hubspot-mcp-extended MCP server](https://glama.ai/mcp/servers/calypsoCodex/hubspot-mcp-extended/badges/card.svg)](https://glama.ai/mcp/servers/calypsoCodex/hubspot-mcp-extended)

Score Badge

Copy to your README.md:

[![hubspot-mcp-extended MCP server](https://glama.ai/mcp/servers/calypsoCodex/hubspot-mcp-extended/badges/score.svg)](https://glama.ai/mcp/servers/calypsoCodex/hubspot-mcp-extended)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/calypsoCodex/hubspot-mcp-extended'

If you have feedback or need assistance with the MCP directory API, please join our Discord server