mcp-nimble-crm

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools target distinct resource-action pairs, but a few like create_note/create_contact_note and get_contacts_by_ids/get_contact could cause misselection. Descriptions generally clarify the differences, though the sheer number of tools increases the chance of confusion.
Naming Consistency5/5
All tool names consistently use snake_case with a verb_noun or verb_noun_qualifier pattern. Even exceptions like exit_lead_successful and get_won_deals_last_month follow the verb-first convention.
Tool Count2/5
At 62 tools, the server is far beyond the typical well-scoped range. While the broad CRM domain partly justifies the count, the sheer number creates unwieldy navigation and includes redundant variants like delete_contact, delete_contacts, and delete_contacts_by_query.
Completeness3/5
Contact, deal, pipeline, and note coverage is robust, but tasks and activities only support create/list with no update/delete, and message drafts lack update/delete/send. These are notable lifecycle gaps for a CRM.
Average 3.7/5 across 59 of 62 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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, the description should explain the consequences of archiving, but it only repeats the verb. It does not disclose reversibility, state change, side effects, or any behavioral details, leaving the agent without essential information.
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 short and front-loaded, with no wasted words. However, it is under-specified; the conciseness comes at the cost of essential information, making it not appropriately sized for the tool's needs.
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, the description is inadequate. It does not explain what archiving does, how it affects the pipeline, or when to use it. The output schema may provide return type, but the side effects are unclear.
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 description labels pipeline_id as 'The Nimble pipeline ID', which adds minimal context (system name) but no format, constraints, or source. Given 0% schema coverage, it only partially compensates for the bare schema field.
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 a deal pipeline' directly restates the tool name without adding specificity, such as what archiving entails or how it differs from deleting or unarchiving. It is a tautology that provides no additional 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 choose this tool over alternatives like delete_deal_pipeline or unarchive_deal_pipeline. The description gives no context 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, the description carries the full burden of behavioral disclosure. It mentions the action applies 'from all deals', which indicates a broad scope, but it does not disclose irreversibility, permission requirements, or whether the tag definition itself is deleted. This leaves the destructive nature and side effects 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 very brief and front-loaded, with no filler. The 'Args' section is slightly redundant with the schema but is acceptable. Overall, it earns its place but could benefit from a bit more detail without becoming 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?
For a destructive tool with no annotations and no schema-level parameter descriptions, this description is insufficient. It fails to specify the global effect on all deals, whether the action is reversible, or what the tool returns. The existence of an output schema does not compensate for missing behavioral context.
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 0%, so the description must compensate. The only parameter, tag_name, is described as 'Tag name to delete', which adds minimal meaning beyond the schema's field name. It does not explain where to find valid tag names or any format constraints.
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 the action ('delete/unlink') and resource ('deal tag'), and adds scope ('from all deals'). This helps distinguish it from siblings like rename_deal_tag or add_tags_to_deals, though the dual verb 'delete/unlink' creates slight ambiguity about whether the tag entity is destroyed or only its associations.
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 rename_deal_tag or add_tags_to_deals. The description lacks exclusions, prerequisites, or a note about the scope of impact compared to other tag 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 provided, the description carries the full burden of behavioral disclosure. It only states the action and arguments, but does not mention potential side effects, reversibility, required permissions, or what happens to the lead's previous stage. 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 very concise and front-loaded with the main action, followed by an Args block. It avoids fluff, but the brevity comes at the cost of missing usage and behavioral context, so it is not maximally effective.
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 meaningful mutation with no annotations or usage guidance. While the output schema is present, the description doesn't cover prerequisites, side effects, or when to choose this tool over similar stage-transition tools. Given the complexity and sibling set, this description is incomplete.
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 0%, and the description merely restates the parameter names with minimal context (e.g., 'lead_id: The contact/lead ID'). It does not explain how to find these IDs, relationships between them, or any constraints, so it adds little value beyond the raw 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 uses a specific verb 'Move' with a clear resource 'lead (contact)' and target 'pipeline stage', making the core action unambiguous. However, it does not explicitly contrast with sibling tools like exit_lead_successful or undo_lead_transition, which also deal with lead stage changes, so differentiation is implicit via the name rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternative pipeline/stage tools such as exit_lead_successful or list_contact_pipelines. The description lacks any conditions, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Delete' without addressing permanence, side effects, authorization requirements, or what happens to related data. The description adds minimal behavioral context beyond the action itself.
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, with no filler words. It front-loads the action and only includes necessary parameter lines. However, the under-specification of behavioral context slightly reduces its value, but conciseness itself is good.
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 having an output schema, the description does not address key contextual aspects such as whether the deletion is permanent, potential errors, or relationships to other entities. The tool is simple but the description is too sparse to be considered complete for a mutation 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?
The description explicitly identifies deal_id as 'The Nimble deal ID' and note_id as 'The note ID,' which adds slight context beyond the schema's minimal titles. However, it does not explain formats, sources, or relationships, and with 0% schema description coverage, it only partially compensates.
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 a note from a deal,' which specifies the action (delete) and the resource (note within a deal). This distinguishes it from sibling tools like delete_note or delete_deal, though it does not explicitly call them out.
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 alternative deletion tools (e.g., delete_note, delete_contact). There is no mention of prerequisites, such as requiring deal and note IDs ownership or 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?
There are no annotations provided, so the description carries the full burden for behavioral disclosure. It states the operation is an undo of a recent transition, but does not disclose side effects, whether the transition is actually removed or reverted, permission requirements, or behavior when no recent transition exists. This is minimal 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 two sentences plus a parameter list, with no filler. The purpose is stated first, and the parameter explanations are concise. However, it is quite terse and could benefit from a bit more context without becoming 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?
For a 2-parameter mutation tool with no annotations, the description omits important details such as what constitutes a 'recent' transition, whether the operation is reversible, and what the output schema represents. It describes the operation at a high level but leaves key operational questions unanswered.
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 no descriptions (coverage 0%), so the description's 'Args' section provides the only explanations: lead_id is the contact/lead ID and pipeline_id is the pipeline ID. This adds basic clarity but does not go beyond what the parameter names imply, such as format or required relationship.
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 undoes a recent won/lost transition for a lead, using a specific verb and resource. This distinguishes it from siblings like exit_lead_successful and exit_lead_unsuccessful, which create such transitions. However, it does not elaborate on what 'undo' entails (e.g., reverting to previous stage).
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 explicit guidance on when to use this tool versus alternatives like exit_lead_successful/unsuccessful or move_lead_to_stage. It does not mention prerequisites (e.g., a transition must have occurred) or exclusions. The usage context is only implied by the verb 'undo'.
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, but it only states the basic delete operation already evident from the name. It does not disclose whether deletion is permanent, cascades to related records, requires permissions, or what the response contains.
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, with one sentence for purpose and an explicit Args section. Every element is functional, 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 destructive tool with no annotations, the description is incomplete. It omits behavioral details like irreversibility, error scenarios, and side effects, though an output schema exists. The agent would need additional context to safely invoke this 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?
Schema description coverage is 0%, so the description must compensate. It adds 'The Nimble note ID' to note_id, which clarifies its meaning slightly, but lacks format, source, or constraints beyond what the schema's type and required fields already provide.
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 'Delete a note by ID' with a specific verb and resource. It distinguishes from sibling tools like list_notes, get_note, and delete_deal_note by explicitly targeting notes.
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 exclusions, such as when to use delete_deal_note instead, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies mutation via 'update' but doesn't state effects like reversibility, permissions, or error behavior, nor does it mention what the output contains.
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-loading the purpose in one sentence followed by a succinct parameter list. Every element earns its place with no redundancy.
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 update tool with an output schema present, the description is minimally adequate but lacks important context like prerequisites or failure semantics. The parameter list is complete, but the overall completeness is limited given no annotations or behavioral details.
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 0%, so the description's argument list adds meaning beyond the schema by identifying each param's role (e.g., 'The Nimble deal ID', 'New title'). However, it's minimal and doesn't clarify optionality or constraints, which the schema partially signals with defaults.
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 'Update a deal note' with a specific verb and resource, identifying it as a mutation tool for deal notes. It distinguishes from siblings like update_note by the 'deal' qualifier, though it doesn't explicitly mention alternatives.
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, prerequisites, or exclusions. The description lacks any context about typical scenarios or required prior actions.
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. It only lists parameters and constraints; it does not mention write effects, permissions, error cases, or return values. The insert_after parameter implies ordering, but the tool's broader behavioral profile is unaddressed.
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?
Concise, front-loaded with a clear purpose, followed by a compact argument list. No redundant or non-informative text.
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 create operation, the description is adequate but incomplete. It lacks information about return values, conflicts, or permissions. The presence of an output schema helps, but the description does not reference or summarize it.
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 has no descriptions (coverage 0%), so the description's parameter details are essential. It provides character limits, allowed contact types, and optional insert_after semantics, adding meaning beyond the raw 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 tool creates a new contact fields tab, with a specific verb and resource. It distinguishes from sibling tools like create_contact_field by focusing on tabs, but does not explicitly contrast with other tab/group creation 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 like create_contact_field_group or create_contact_field. The description only defines the action without contextual usage cues 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 provided, the description bears full responsibility for disclosing behavioral traits. It only states the action and optional parameters, omitting side effects (e.g., whether the lead is removed from the pipeline, whether the transition is reversible, or if any permissions are required).
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 and well-structured: a one-sentence summary followed by a clear Args block. No unnecessary information is included.
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 is simple and an output schema exists, so return values are covered. However, the description lacks context about preconditions, side effects, or relationships to related tools like exit_lead_successful and undo_lead_transition, making it minimally adequate.
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 Args block adds little beyond the schema. For example, 'pipeline_id: The pipeline ID' is a tautology, and 'lost_reason: Optional lost reason' repeats the name. With schema description coverage at 0%, the description fails to meaningfully compensate for the lack of parameter details.
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 "Exit a lead from a pipeline as lost" uses a specific verb and resource, clearly indicating the outcome. It distinguishes itself from the sibling tool exit_lead_successful by specifying 'as lost'.
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 exit_lead_successful for won leads or undo_lead_transition for reverting a transition, leaving the agent without explicit 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 provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly state whether it is safe, require authentication, or paginate results. It lacks any additional context about side effects or limitations.
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. It is appropriately sized for a no-parameter list operation. Every word serves a purpose, and there is no wasted 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?
Given the tool's low complexity (no parameters) and the presence of an output schema, the description is minimally sufficient. However, it lacks usage guidance and any explanation of what a 'column catalogue' is, which leaves room for misinterpretation. The absence of annotations also means the behavioral context is thin.
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, and the schema coverage is trivially 100%. The description adds no parameter information, but none is needed. The baseline score of 4 applies per the rubric for tools with no parameters.
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 ('List') and the resource ('deal column/column-group catalogue'). It is specific enough to distinguish from sibling tools like list_deal_fields and list_deal_pipelines. However, 'column/column-group catalogue' is somewhat ambiguous without additional context on what constitutes a column or column-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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context. It simply states what the tool does. There is no mention of exclusions or alternative tools like list_deal_fields.
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, but it only states that the tool lists fields. It does not disclose return format, read-only assurance, pagination, or any security/permission requirements. The verb 'List' implies a read operation, but no additional behavioral details are given.
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 sentence with no extraneous words, making it concise and easy to scan. It is appropriately front-loaded with the action and resource, and every word 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 is simple with zero parameters and an output schema, so the description does not need to explain return values. However, it lacks context about the distinction between standard and per-pipeline fields, potential use cases, and why one might choose this over other deal-related tools, making it only minimally complete.
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 the description has no parameters to document. According to the rubric, a zero-parameter tool gets a baseline of 4, and the description's mention of 'standard fields and per-pipeline fields' adds a small amount of context about the output scope, though it does not affect parameter 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 uses the specific verb 'List' and identifies the resource as 'deal standard fields and per-pipeline fields,' making the tool's function clear. However, it does not explicitly distinguish this from sibling tools like list_contact_fields, though the deal-specific scope provides implicit 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 list_deal_pipelines or list_contact_fields. There are no stated prerequisites, exclusions, or recommended use cases, leaving the agent to infer the tool's role from its name alone.
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 disclosing behavior. It simply states the action without explaining consequences (e.g., whether archiving is reversible, what happens to deals in the stage, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, with a clear one-sentence purpose followed by parameter explanations. No unnecessary words or filler.
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 simplicity, an output schema exists to explain return values, and the parameter list is small. However, the description omits important behavioral context (e.g., side effects, prerequisites), making it only minimally adequate.
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 0%, but the description adds brief parameter meanings: pipeline_id is 'The Nimble pipeline ID' and stage_id is 'The stage ID to archive.' This helps, but it lacks details on formats, constraints, or the relationship between the two 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 tool's function: 'Archive a pipeline stage.' It uses a specific verb and resource, distinguishing it from sibling tools like archive_deal_pipeline, which archives an entire pipeline.
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 context is provided. The description does not explain when to archive a stage, what prerequisites exist (e.g., stage must belong to a pipeline), or how this differs from deletion or other alternatives.
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 states the create action and lists parameters, without mentioning side effects, prerequisites, permissions, or whether the operation is reversible. For a mutating 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 brief and front-loaded with a clear summary, followed by a structured Args list. However, the parameter descriptions for color and description are redundant with their names, adding minor fluff. Overall, it is concise but could be slightly more informative without becoming 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?
For a multi-parameter mutation tool with no annotations, the description lacks important context. It does not mention prerequisites (e.g., admin rights), whether default stages are created, the format for 'color', or how the tool fits into the pipeline lifecycle. The output schema may cover return values, but behavioral and operational context is 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?
The description adds useful constraints for 'name' (1-200 chars) and 'default_currency' (ISO-4217), but 'color' and 'description' are explained with tautologies ('Pipeline color', 'Pipeline description') that offer no added meaning beyond the parameter names. With 0% schema description coverage, this partial compensation is only adequate.
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 explicitly states 'Create a new deal pipeline in Nimble CRM' with a clear verb and resource. This distinguishes it from sibling tools like update_deal_pipeline, delete_deal_pipeline, and archive_deal_pipeline, which serve different actions.
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 the tool is for creating pipelines but provides no explicit guidance on when to use it instead of alternatives. Sibling tools exist for updating or deleting pipelines, but no reference or exclusion is given, leaving usage context largely 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?
No annotations are provided, and the description does not disclose destructive consequences, reversibility, or cascading effects. 'Delete' is terse and lacks 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?
Extremely short and front-loaded with the core action. The Args section is redundant but harmless; no wasted words.
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 delete tool with an output schema, the description covers the action and parameter, but lacks safety/permission context and error behavior, which matters because there are no annotations.
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 description includes a minimal parameter explanation ('The Nimble deal ID'), but it adds little beyond the schema's name and type. No format or lookup guidance.
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 ('Delete') and resource ('a deal') with the required identifier ('by ID'). Distinguishes from siblings like delete_deal_tag and get_deal.
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 vs alternatives; no mention of prerequisites or exclusions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Create' and lists parameters, but does not mention any required permissions, reversibility, side effects, or effects on existing pipeline stages. The mutation nature is already evident from the tool name, so the description adds no extra behavioral insight.
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 compact docstring with a clear opening sentence and an Args list. It is concise and well-structured, with each parameter explanation earning its place. Some explanations are redundant with parameter names, but the overall format is efficient and easy to scan.
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 is a straightforward create operation with a simple 5-parameter schema and an output schema present. The description covers all parameters and states the action, but it omits any prerequisites (e.g., pipeline must exist) or notes about stage ordering. While the output schema handles return values, the lack of caveats makes it only minimally-sufficient for complete 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 schema has 0% description coverage, so the description is the only source of parameter meaning. It adds useful context for expected_days ('Expected number of days a deal spends in this stage') and default_probability ('Default win probability (0-100)'). However, pipeline_id, name, and description are merely restated without additional clarification, making the added value partial.
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 begins with 'Create a new stage within a deal pipeline', which is a specific verb and resource. This clearly distinguishes it from sibling tools like update_pipeline_stage and archive_pipeline_stage. The scope is unambiguous and leaves no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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, nor does it mention any exclusions. The verb 'Create' implicitly suggests that this is for new stages only, but there is no direct reference to update or archive tools. The usage context is implied rather than stated.
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' and lists arguments without mentioning permissions, reversibility, side effects on related entities, or any other operational details beyond the 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 compact and well-structured: a single action sentence followed by a clean parameter list. Every line conveys useful information with no fluff or repetition, making it easy to scan.
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 6 parameters, no annotations, and an output schema present, the description adequately documents all parameter meanings and provides a clear action. However, it lacks usage guidance and any operational caveats, making it a minimum-viable description rather than a comprehensive one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides an Args section that explains each parameter, such as 'related_contacts: Comma-separated contact IDs to associate' and 'due_date: Due date, e.g. YYYY-MM-DDTHH:MM:SS.' This adds meaningful format and semantic context that the schema lacks (0% coverage), fully compensating for the schema's silence.
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 task in Nimble CRM.' with a specific verb and resource, clearly identifying the tool's function. It distinguishes from sibling tools like create_contact or create_deal by naming 'task' as the target, though it lacks additional scope or distinguishing details.
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, nor any exclusions or context about task-related operations. The description only states the action, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the action without explaining the effects of unarchiving, any required permissions, reversibility, or what happens after success. This is a mutation tool with no behavioral detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, followed by an Args section. It is appropriately concise for a simple tool, with no redundant words. The Args repeat schema information but add the 'Nimble' context, making it justifiable.
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 is simple (one parameter) and has an output schema (not shown), which reduces the need to explain return values. However, with no annotations and no behavioral context, the description is minimally adequate but lacks crucial information about side effects and preconditions. It does not fully cover the context for an agent to invoke it correctly in all scenarios.
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 0% description coverage, and the description adds 'The Nimble pipeline ID' to the parameter, providing context beyond the schema's type/title. However, it does not specify formats, constraints, or examples, leaving room for more detail.
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 specific verb 'Un-archive' with a clear resource 'deal pipeline', which precisely defines its function and distinguishes it from the sibling tool 'archive_deal_pipeline'. This is unambiguous and directly states the tool's purpose.
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 (to un-archive a deal pipeline) but provides no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusions. It lacks the 'when/when-not' clarity that would earn a higher 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 implies mutation via 'Add' but does not disclose side effects, permissions, idempotency, or error behavior, which is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a one-sentence summary followed by a minimal Args list. No fluff, and the action is front-loaded.
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 2-param tool with an output schema, the description covers purpose and parameters. However, it omits usage context and behavioral details beyond the basic action. With no annotations, more context would be expected, but it is minimally adequate.
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 0% (only titles 'Reason' and 'Pipeline Id'). The description adds meaningful semantics: 'pipeline_id: The Nimble pipeline ID' and 'reason: Reason description', fully compensating for the schema gaps.
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?
Description clearly states 'Add a new lost-reason option to a pipeline' – a specific verb ('Add') and resource ('lost-reason option'). This distinguishes it from sibling tools, none of which mention lost reasons.
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 versus alternatives. It does not reference prerequisites, exclusions, or sibling tools like create_deal_pipeline or archive_pipeline_stage.
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. However, it only states the action and does not disclose potential error behavior, permission requirements, or explicitly confirm that this is a read-only operation beyond the verb 'Get'. It adds no behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one main sentence and a single parameter explanation, with no redundant words. It is front-loaded and well-formatted, earning its place despite its brevity.
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 is simple (one parameter, output schema exists), so the description is mostly adequate for an agent to invoke it correctly. However, it lacks explicit behavioral context such as error conditions or read-only confirmation, which a complete description might include, especially given the absence of annotations.
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 0% description coverage, but the description adds a brief explanation of pipeline_id as 'The Nimble pipeline ID,' which provides some context beyond the schema's title 'Pipeline Id'. It clarifies the namespace but does not offer format details, examples, or how to obtain the ID.
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 the specific verb 'Get' with the resource 'single deal pipeline' and the scope 'by ID', clearly distinguishing it from list/create/update/delete pipeline siblings. It exactly matches the tool name and leaves no ambiguity about what it does.
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 a specific pipeline ID, but it does not explicitly mention alternatives or exclusions. For example, it does not say to use list_deal_pipelines for retrieving all pipelines, so the guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 states the core behavior ('List contacts') and implies pagination through per_page and page, but adds no extra context (e.g., read-only nature, sorting, rate limits, or what fields are returned). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, placing the main function in the first sentence followed by a clear Arg list. Every sentence or phrase adds value, with no fluff or repetition.
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 4-parameter, all-optional list tool with an output schema, the description covers all parameter semantics and the core action. It does not detail return values (output schema exists) but lacks any mention of alternative tools or edge cases, which slightly reduces completeness in the broader tool context.
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 no descriptions (0% coverage), so the description's parameter explanations are essential. It adds meaning beyond the schema by explaining record_type values ('person', 'company', 'all'), keyword search scope ('name, email, etc.'), and pagination semantics ('default 30', 'starts at 1'). This compensates well for the schema gap.
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 with a specific verb and resource: 'List contacts with optional keyword search.' It distinguishes from get_contact (single contact) and get_contacts_by_ids (specific IDs) but does not explicitly differentiate from the sibling tool search_contacts, so it is not a full 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?
No guidance is provided on when to use this tool versus alternatives such as search_contacts or list_contact_ids. The description only explains parameters, with no exclusions, prerequisites, or explicit usage scenarios, leaving the agent to infer.
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 action (list) and parameter semantics. It doesn't disclose return format, pagination behavior, ordering, or any safety profile. 'List' implies read-only, but this is not explicit, and no other behavioral traits are mentioned.
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: a one-line purpose followed by a clear Args block. Every sentence earns its place, and there is no wasted text or redundancy.
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 list tool with an output schema, the description covers the basics. However, it lacks any note on default behavior (e.g., that limit defaults to 30 in the schema), ordering, or potential pitfalls. Without annotations, more behavioral context would be expected, so it feels slightly incomplete.
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 description explains both parameters (starts_with and limit) in plain language, which is crucial because the input schema has 0% description coverage. It adds meaning beyond the schema by specifying that starts_with filters tag names and limit caps results. Simple but effective.
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 starts with 'List deal tags' which is a specific verb (list) and resource (deal tags), clearly distinguishing it from sibling tools like delete_deal_tag, rename_deal_tag, and replace_tags. The optional prefix filter is also mentioned, adding 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?
There is no explicit guidance on when to use this tool versus alternatives. The mention of 'optionally filtered by prefix' is a parameter condition, not a usage scenario. No exclusions or alternative tool recommendations 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 for behavioral transparency. It does not explicitly state that the tool is read-only, though 'List' implies it. It mentions 'Page number (starts at 0)' and 'Results per page,' which hints at pagination behavior, but lacks details on response format, authentication, rate limits, or any side effects. The description is too sparse to fully disclose 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 appropriately sized, with the main purpose stated in a single opening sentence followed by a clean parameter list. Every line provides necessary information without redundancy, making it well-structured and easy to scan.
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?
The tool is a simple list operation with three optional parameters and an output schema, so the description does not need to explain return values. It adequately covers the parameters and basic purpose. However, it lacks usage guidance and any caveats, which would make it more complete for an agent deciding when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter titles and defaults with no descriptions (0% coverage). The description compensates by explaining each parameter meaningfully: 'Comma-separated recipient filter' clarifies the format, 'Page number (starts at 0)' adds the zero-based indexing detail, and 'Results per page' defines per_page. This adds significant 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 clearly states the tool's function: 'List draft messages in Nimble CRM.' It uses a specific verb and resource, making the purpose obvious. However, it does not explicitly distinguish from sibling tools like create_message_draft, though the difference is self-evident from the names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 any prerequisites, exclusions, or related tools. The only content beyond the primary sentence is the parameter list, which offers no contextual usage advice.
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 burden. It only states 'Rename a deal tag' without disclosing potential side effects, such as impact on existing deals using the tag, duplicate handling, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with just two sentences and a clean Args list. No redundant information is included.
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 mutation tool, the description is adequate but minimal. It lacks usage guidance and behavioral details, though the output schema covers return values. Given no annotations, a bit more context about side effects would improve completeness.
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 description explains the two parameters: tag_name as current tag name and new_tag as new tag name. This adds clarity beyond the bare schema titles, which is valuable given 0% schema description coverage.
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's function: 'Rename a deal tag.' This is a specific verb+resource and distinguishes it from sibling tools like delete_deal_tag.
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 such as delete_deal_tag or add_tags_to_deals. The description only states the action without any contextual cues 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 provided, the description carries full burden for behavioral disclosure. It only says 'Delete' and provides no information about irreversibility, required permissions, what happens with invalid IDs, or the response format. This is a significant gap for a destructive 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 extremely concise, with a front-loaded main sentence and a clear Args section. Every word adds value, with no fluff or redundancy.
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 being a simple tool, the description is minimal. It lacks context about when to use this tool over delete_contact or delete_contacts_by_query, and does not disclose potential side effects or limitations. The lack of behavioral detail makes it incomplete for an agent to fully assess the 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?
The description adds critical meaning beyond the schema by stating that contact_ids is a comma-separated list. Since schema description coverage is 0%, this clarification is essential and helps the agent format the parameter correctly.
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 'Delete one or more contacts by ID,' using a specific verb and resource. It effectively distinguishes itself from singular delete_contact by saying 'one or more' and from query-based deletion by specifying 'by ID.'
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 contact IDs to delete, but does not explicitly contrast with sibling tools like delete_contact (singular) or delete_contacts_by_query. This leaves the choice somewhat ambiguous despite the 'one or more' hint.
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 does not disclose any behavioral traits such as read-only safety, return value, or error handling. It only states the action without describing what happens on success or failure.
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 with two short lines: the first states the purpose, the second documents the parameter. No unnecessary words or repetition, and the key information is front-loaded.
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 simplicity (one parameter, output schema provided), the description is largely sufficient. It could mention error behavior or typical return values, but the output schema fills the return-shape gap. The minimalism is acceptable for a getter.
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 0% description coverage, but the description manually explains the parameter as 'The Nimble deal ID'. This adds a small semantic cue beyond the schema's type and title, identifying it as a Nimble-specific identifier, though it lacks format or acquisition details.
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 'Get a single deal by ID', specifying the action (get), the resource (deal), and the selection method (by ID). This distinguishes it from sibling tools like list_deals, create_deal, and delete_deal.
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 the tool: when you have a deal_id and need a single deal. However, it does not explicitly mention alternatives or when not to use it, such as using list_deals for multiple deals.
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 full burden. It states the read-only nature via the verb 'get', but does not disclose behavior such as error handling when the note_id is not found, pagination (not applicable), or any prerequisites like authentication. It adds minimal context beyond what is inherently obvious from the name and schema.
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 at two lines, with the core purpose front-loaded. The 'Args' section is neatly structured and contains no redundant information. Every word earns its place, making it easy for an agent to parse quickly.
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 simplicity (single parameter) and the existence of an output schema, the description adequately covers the essentials. It would benefit from a mention of when to use list_notes as an alternative, but the shortfall is minor. For a straightforward getter, this is sufficient.
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 0% description coverage, so the description's 'note_id: The Nimble note ID' provides some additional meaning by indicating that the ID is a Nimble-specific identifier. However, it does not elaborate on format, uniqueness, or relationship to other objects. It implicitly confirms the parameter is required, which is already shown in 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's function with a specific verb and resource: 'Get a single note by ID.' It specifies the key (ID), making it distinct from sibling tools like list_notes (which lists multiple) and update_note/delete_note (which modify). The purpose is unambiguous and immediately actionable.
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 that list_notes should be used when needing multiple notes or that other note operations exist. The only hint is the phrase 'single note', but it does not explicitly exclude other use cases or name alternatives.
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 full burden. It only says 'update', which implies mutation, but it does not disclose whether changes are reversible, what permissions are needed, whether it is a partial update (only specified fields) or full replacement, or what consequences occur for unspecified fields. 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 opening sentence is concise and front-loaded. The 'Args' block is somewhat redundant with the input schema, but the overall length is appropriate and well-organized. It earns a 4 rather than 5 because the Args section adds little beyond listing parameter names already present in the schema.
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 an output schema, so return values are not the description's responsibility. However, with no annotations and a simple one-sentence purpose, the description provides only the minimal viable context: what it updates and which parameters are involved. It lacks guidance on usage context (e.g., when to prefer over other pipeline tools) and behavioral details (e.g., partial vs full update), making it incomplete for a tool with no structured safety annotations.
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 0%, so the description must provide meaning. It adds one useful clarification: 'The Nimble pipeline ID' for pipeline_id, which goes beyond the schema's 'Pipeline Id' title. However, the other parameters (name, description, color) are merely restated without any additional semantics (e.g., length limits, allowed formats, default behaviors).
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's verb ('Update'), resource ('deal pipeline'), and scoping ('existing'), plus the specific fields ('name, description, or color'). This distinguishes it from sibling tools like create_deal_pipeline, get_deal_pipeline, and delete_deal_pipeline.
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 word 'existing' implies it is used for updating already-created pipelines rather than creating new ones, giving clear context. However, it does not explicitly name alternative tools (e.g., create_deal_pipeline for new pipelines) or provide exclusion criteria.
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 full burden. It does not disclose whether the draft is saved, whether it sends anything, whether authentication is required, or what happens upon success. It only states the action and parameter meanings, leaving significant behavioral aspects undisclosed.
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, leading with the purpose sentence and using a concise 'Args:' block to define parameters. Every sentence adds information without redundancy.
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 output schema exists, so return values need not be described. The parameter meanings are covered, but the description lacks behavioral context (e.g., draft lifecycle) and usage guidance, making it complete only for the simplest operation level.
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 has no descriptions (0% coverage), but the description lists each parameter with a brief meaning: subject, body, and to (with comma-separated recipient format). This adds functional meaning beyond the schema titles. However, it doesn't provide details like validation rules or optionality nuances beyond the required fields.
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 the imperative verb 'Create' with the specific resource 'a draft message' and target 'Nimble CRM', clearly distinguishing it from sibling tools like list_message_drafts which retrieves drafts. It 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?
It implies usage (when you need to create a draft message) but does not explicitly mention when not to use it or suggest alternative tools. No exclusions or alternative references are provided.
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 full burden. It discloses useful behavioral details: contact_ids are comma-separated and limited to 1-10, note can contain HTML, and note_preview falls back to the first 100 characters if empty. However, it does not mention permission requirements, error behavior, idempotency, or what is returned, leaving notable gaps for a create mutation.
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 highly efficient. A one-sentence purpose statement is followed by a compact Args list, with every detail earning its place. No fluff or redundancy, and the front-loaded summary gives immediate clarity.
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?
An output schema exists, so return values need not be explained. The description covers all three parameters with sufficient depth, and the tool's core behavior is straightforward. The main missing piece is usage guidance relative to the similar create_contact_note sibling, but for a create operation with clear parameter semantics, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type information and no descriptions, so the parameter explanations in the description are essential. The description adds rich semantics: contact_ids format and cardinality, note content type (HTML allowed), and the preview fallback rule. This far exceeds the schema's bare structure.
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 ('Create') and resource ('note') with a clear attachment target ('attached to one or more contacts'). It is unambiguous in what the tool does, but the presence of a sibling tool named create_contact_note introduces potential confusion; the description does not explicitly differentiate from that sibling.
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 create_contact_note or update_note. There are no exclusions, prerequisites, or context signals indicating the intended use case, leaving the agent with no basis for tool selection decisions.
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 full burden for behavioral disclosure. The description only states the action and parameters, but does not mention side effects (e.g., changes to lead status, pipeline stage, reversibility), permissions, or what happens after exit. 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 a single sentence plus a compact parameter list. It is front-loaded with the purpose and every line adds value, especially given the lack of schema descriptions. No unnecessary words.
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 core action and all parameters, but lacks context about when to use the tool vs siblings and does not describe the outcome or side effects beyond 'as won'. An output schema exists, so return values are covered, but the missing usage and behavioral context make it only partially complete.
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 has 0% description coverage, but the description's Args section provides brief meaning for all three parameters: lead_id as 'contact/lead ID', pipeline_id as 'pipeline ID', and notes as 'Optional notes about the transition.' This adequately compensates for the bare 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's function: 'Exit a lead from a pipeline as won.' This is a specific verb+resource+outcome combo that distinguishes it from siblings like exit_lead_unsuccessful and undo_lead_transition. No 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 usage context is implied by the phrase 'as won' and the tool name, but there is no explicit mention of when to use this tool vs alternatives like exit_lead_unsuccessful or move_lead_to_stage. It provides no 'when to use' or 'when not to use' guidance beyond the basic action.
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 states the scope ('current user's deals') but omits details about return format, pagination, sorting defaults, or any side effects. The operation appears read-only but this is not explicitly stated, and no info about rate limits or authentication is given.
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 succinct and well-structured: a single purpose sentence followed by an Args block. Every word contributes value, with no filler or redundant repetition of schema defaults. It is appropriately sized for the tool's simplicity.
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 is a straightforward list operation with an output schema present, the description sufficiently covers the essentials. The main gap is the lack of usage guidelines (captured in dimension 2), but for the simple use case, the description is otherwise complete. It could mention default sort order or pagination behavior, but those are partially covered by schema defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains both parameters beyond the empty schema. 'sort' is clarified with a format example ('name:asc'), and 'limit' is defined as 'Max deals to return.' Since schema description coverage is 0%, this is the only source of meaning and it handles both parameters clearly.
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's purpose: 'List all of the current user's deals.' This uses a specific verb ('list') and resource ('deals') with an explicit scope ('current user's'), distinguishing it from sibling tools like list_contacts or list_notes.
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 any explicit guidance on when to use this tool versus alternatives such as list_pipeline_deals_by_stage or get_won_deals_last_month. There is no mention of exclusions, prerequisites, or preferred scenarios, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates the tool updates a field, which implies mutation, but does not disclose potential side effects, permissions required, or whether changes are immediately visible or reversible. The description only lists parameters without elaborating on the update behavior, leaving the agent to infer the consequences.
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 a one-sentence purpose followed by a clean, structured list of arguments. Every line provides needed information without excess. It is appropriately sized for a straightforward update operation.
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 moderate complexity and lack of annotations, the description covers the purpose and parameters but omits behavioral context such as error handling, prerequisites, or effects on related data. An output schema exists, so return values are documented, but the description still lacks completeness regarding the implications of the update operation. It is adequate but not thorough.
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?
Since schema description coverage is 0%, the description must explain parameters. It does so by providing brief meanings for each parameter, such as 'presentation_json: JSON string for new presentation settings' and 'group_id: New group ID to move the field into.' This adds value beyond the bare schema names, though some descriptions (e.g., field_id: 'The field ID') are redundant. Overall, it compensates well for the schema's lack of 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 the verb and resource: 'Update an existing custom contact field.' This distinguishes the tool from sibling tools like create_contact_field and delete_contact_field, as it specifically targets updating existing fields.
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 modifying existing custom contact fields but does not explicitly provide when-to-use versus alternatives. It does not mention that create_contact_field should be used for new fields, nor does it provide exclusions or alternative scenarios. The context is clear enough for a simple update but lacks explicit 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 carries the full burden of behavioral disclosure. It merely states the action without explaining whether tags are appended or replace existing tags, how partial failures are handled, or what permissions are required. This is a significant gap for a bulk 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 that states the tool's purpose, followed by a concise Args list. Each sentence earns its place, with no redundant or extraneous 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?
Although an output schema exists (as noted in context signals), the description is incomplete for a bulk mutation tool. It omits critical details such as idempotency, error handling, batching behavior, and whether existing tags are preserved. This leaves the agent uncertain about side effects 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 input schema provides zero description coverage (0%), so the description appropriately compensates by explaining both arguments: query_json as a JSON-encoded search query and tags as comma-separated values. While basic, this adds essential meaning beyond the schema's bare titles.
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 the specific verb 'assign' and identifies the resource as 'tags to all deals matching an advanced search query.' It clearly distinguishes from sibling tools like 'replace_tags' and 'rename_deal_tag' that operate on individual deals by emphasizing the bulk, query-based scope.
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 makes it clear that this tool is for bulk assignment based on a search query, which differentiates it from per-deal operations. However, it does not explicitly state when to avoid using it or mention alternatives, leaving some room for interpretation.
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 adds useful constraints (max 30 IDs, comma-separated format) but does not disclose behavior for invalid IDs, partial successes, or limits exceeded. Some behavior is inferable from 'standard contact listings', but error handling and edge cases are absent.
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, with a front-loaded declarative sentence and a minimal args section. Every word earns its place; no fluff or repetition.
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 simple one-parameter batch getter with an output schema present, the description covers the essential constraints (count limit, input format). It lacks nuance about failure modes or alternatives, but given the tool's simplicity and available output schema, it is reasonably complete.
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 0%, so the description must compensate. It does so by explaining contact_ids as 'Comma-separated contact IDs (max 30)', which adds format and limit semantics beyond the bare schema type 'string'. This fully documents the only parameter.
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's function with a specific verb ('Return'), resource ('contact listings'), and scope ('up to 30 explicit IDs'). It distinguishes itself from siblings like get_contact (single ID) and search_contacts (query-based) by emphasizing explicit IDs and batch handling.
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 explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions (e.g., 'use get_contact for a single contact') or context for choosing it over list_contacts or search_contacts. The usage is only implied by the tool name and args.
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 full behavioral disclosure burden. It states the computation (sum and count) but leaves the meaning of 'last month' ambiguous (e.g., calendar month vs. rolling 30 days, timezone). It does not address potential currency handling or data scoping, though the simplicity of a read-only aggregate is evident.
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 is immediately understandable. It front-loads the verb and resource, containing no filler or redundancy. Every word contributes to the meaning.
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?
The tool is simple, has zero parameters, and has an output schema, so the description does not need to explain return value structure. It covers the core purpose well. The only notable gap is the precise definition of 'last month', which would make the description fully complete. Despite this, the description is sufficient for a zero-parameter aggregate 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 tool has no parameters, so the schema is trivially covered (100%). The description adds value by specifying the output metrics (sum and count), which directly aligns with the output schema and provides semantic clarity beyond the empty parameters object.
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 (get sum and count), the resource (deal amounts), and a time filter (won in the last month). This clearly distinguishes it from sibling tools like list_deals or get_deal, which retrieve individual deals rather than aggregate metrics.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that list_deals or get_deal should be used for individual deal details, nor does it specify any prerequisites or exclusions. The usage context must be inferred from the name and description.
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 full responsibility for behavioral disclosure. It only states the basic action and parameter meanings, omitting any details about read-only nature, pagination, owner handling (e.g., deals without owners), or auth requirements. This is minimal behavioral transparency.
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 sections: a one-sentence purpose statement and a short Args list. Every sentence contributes value and the format is easy to scan, with no redundant or extraneous content.
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?
With a simple tool and an output schema available, the description covers the essential aspects: purpose and all parameters. The only notable gap is the ambiguity of the sort field (which fields are valid), but this is a minor omission given the schema and output schema provide additional structured context.
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 0%, so the description compensates by explaining all three parameters: pipeline_id is the Nimble pipeline ID, sort follows '<field>:<order>', and limit sets max deals per owner. This adds meaningful context beyond the raw schema, though the explanations are terse.
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 starts with 'List a pipeline's deals grouped by owner,' which clearly states the action (list), the resource (pipeline's deals), and the grouping (by owner). This distinguishes it from the sibling tool list_pipeline_deals_by_stage, which groups by stage. The verb and resource are 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 through the grouping by owner but does not explicitly state when to use this tool versus alternatives like list_pipeline_deals_by_stage or list_deals. There is no mention of exclusions or alternate approaches, so it relies on the user inferring suitability from the title.
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 only the creation intent and parameter purposes, but omits side effects, permission requirements, or behavior like insertion ordering. For a mutation tool, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured with a clear one-line purpose and a compact Args list. Every sentence contributes useful information, with no redundant text.
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?
The description covers all parameters and the core action. Since an output schema exists, the lack of return value explanation is acceptable. Minor omissions like prerequisites or behavior on invalid tab_id prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter beyond the schema, adding constraints (name 1-50 chars), roles (tab_id, logo_id, insert_after), and optionality. With 0% schema description coverage, this fully compensates for the missing schema 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 "Create a new contact fields group" uses a specific verb and resource, clearly distinguishing this from sibling tools like create_contact_field and create_contact_field_tab. It unambiguously states the action and object.
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 of creating a group but does not explicitly state when to use it versus alternatives or mention prerequisites. The usage is implied rather than stated with exclusions.
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 explains that activities are filtered by direction (pending/past) and other criteria, which is useful. However, it does not disclose potential side effects (it's a read operation, but not explicitly stated), sorting behavior, pagination nuances beyond the limit parameter, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a one-line summary followed by a clean bulleted list of arguments. Every line adds value, and there is no unnecessary verbosity.
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?
The description is sufficiently complete for a list tool with an output schema. It covers all filters and the core behavior. Minor gaps include lack of explicit read-only confirmation, pagination behavior, and potential error messages, but these are not critical given the simple nature of the operation and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for all five parameters in the Args section, which is especially valuable given the schema has zero description coverage. It adds clear meaning to direction, limit, contact_ids, deal_ids, and completed, fully compensating for the schema's lack of 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 it lists activities (pending or past) matching filters, using the verb 'list' and resource 'activities'. It doesn't explicitly distinguish from sibling tools like list_deals or list_notes, but the resource is unambiguous given the tool name and parameter details.
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 the tool (to list activities) and details the filters, but it does not explicitly provide when-not-to-use guidance or mention alternatives. The purpose is evident, but there's no comparative context with sibling tools.
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 full burden of behavioral disclosure. It discloses the important sentinel semantics for expected_days and default_probability ('pass -1 to leave unchanged') and the range for default_probability. However, it does not clarify whether name and description, which have default empty strings, are overwritten when omitted, nor does it mention return values or error behavior, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single-sentence purpose followed by a structured argument list. Every sentence and line earns its place, with no filler or redundant information. The use of a code-block list enhances readability and scannability.
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 has six parameters and no annotations, the description covers the basic purpose and parameter semantics but lacks important contextual details. It does not explain the update semantics for optional fields (e.g., whether name and description are always applied, or whether omitted fields are left unchanged), nor does it mention any return value or error conditions. While the presence of an output schema reduces the need to describe return values, the ambiguity around partial updates and potential overwriting of name/description is a meaningful completeness gap.
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 description lists all six parameters with brief functional explanations, compensating for the 0% schema description coverage. It adds meaning beyond the property names by explaining the pipeline_id and stage_id identifiers, and crucially clarifying the sentinel logic for expected_days and default_probability. While not deeply detailed, it gives an agent enough to understand what each parameter represents and how special values behave.
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 begins with 'Update an existing pipeline stage,' which is a specific verb+resource that clearly states the tool's function. It distinguishes itself from sibling tools like create_pipeline_stage and archive_pipeline_stage by focusing on updating an existing stage, leaving no ambiguity about its purpose.
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 updating existing pipeline stages but provides no explicit guidance on when to prefer this tool over alternatives like create_pipeline_stage or archive_pipeline_stage. There is no mention of prerequisites, such as the stage existing, or exclusions, so it offers only implied 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?
No annotations are provided, so the description carries the full burden. It does disclose that presentation_json is required for number/datetime fields, which is useful, but it does not mention side effects, irreversibility, permissions, or any other behavioral traits. For a mutating create operation, this is a 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 a compact, well-organized list. The purpose is front-loaded, and each parameter description is terse yet complete, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no schema descriptions, the description covers all of them accurately, including conditional requirements. The presence of an output schema means return values need not be explained, so the description is fully sufficient 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing every parameter: name length, field_kind enum values, tab_id purpose, presentation_json format with example, optional group_id/insert_after, and multiples semantics. This goes well beyond the bare 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 begins with 'Create a new custom contact field,' using a specific verb ('Create') and resource ('custom contact field') that clearly distinguishes it from sibling tools like update_contact_field, delete_contact_field, and list_contact_fields.
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 use case is implied by the name and opening line: use this when you need to create a new contact field. However, there is no explicit guidance about when not to use it or how it differs from related tools like create_contact_field_group or create_contact_field_tab.
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 simple action of creating a note and does not mention potential side effects, permissions, rate limits, or behavior around note_preview beyond its default. For a write operation, this lack of detail leaves the agent unaware of any implicit constraints.
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 appropriately concise and well-structured. It opens with a one-sentence purpose, followed by a clearly formatted parameter list. Every sentence contributes necessary information, with no redundancy or 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?
For a tool with only three parameters and an output schema, the description supplies the essential purpose and parameter semantics. It could benefit from explicit usage guidance relative to sibling tools, but the scope is simple enough that an agent can likely select and invoke it correctly. The lack of annotation context is partially mitigated by the clarity of purpose.
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?
Even though the schema has 0% description coverage, the description compensates by explaining each parameter in plain terms: contact_id, note, and note_preview. It adds meaningful context beyond the schema's titles, especially noting that note_preview defaults to the full note when omitted. This is valuable for 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 tool's action and target: 'Create a note attached to a single contact.' This specific verb+resource combination distinguishes it from sibling tools like create_note or create_deal_note, which likely handle notes in other contexts. The scope is 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 appropriate context—attaching a note to a contact—and the sibling list shows alternative note-creation tools for other contexts. However, it does not explicitly state when to use this versus alternatives, such as 'use create_note for standalone notes.' Still, the context is clear enough without formal exclusions.
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 transparency burden. It clearly indicates the action (create) and the target (deal note), but it does not disclose side effects, permissions, or response behavior. For a simple CRUD operation, this is adequate but not rich; additional context about potential side effects or preconditions 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 extremely concise, consisting of a one-line purpose statement and a short argument list. It is front-loaded with the key purpose and includes no wasted words.
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 simple nature of the tool (three string parameters, no nested objects) and the presence of an output schema, the description covers the essential information: purpose and parameters. However, it does not explicitly differentiate from other note-related tools, which would improve completeness in the context of many 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?
The input schema has no descriptions (0% coverage), but the tool description provides concise explanations for all three parameters: deal_id, title, and body. This fully compensates for the schema gap, adding meaning beyond the parameter names.
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 a specific action ('Create') and a specific resource ('note attached to a deal'), making the purpose unambiguous. This clearly distinguishes it from generic note creation tools like create_note or create_contact_note.
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 deal-attached notes via the phrase 'attached to a deal,' but it does not explicitly exclude alternatives or reference sibling tools such as create_contact_note. There is no direct when-to-use guidance, but the context is reasonably clear.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the critical side effect that deleting a pipeline also deletes all deals within it. This goes beyond the obvious 'delete' action and is essential for safe usage. However, it does not mention other potential effects such as irreversibility, permissions required, or impact on stages/notes.
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 and well-structured: two sentences plus a parameter explanation. It front-loads the action, highlights the critical side effect, and then defines the parameter. Every sentence earns its place without unnecessary 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?
For a simple one-parameter destructive tool with an output schema, the description covers the main purpose, the most important side effect, and the parameter. It perfectly addresses the core use case and risks. The only gap is the lack of explicit alternative guidance, but that does not detract significantly from completeness for this simplicity level.
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 zero description coverage for pipeline_id, but the description's Args section defines it as 'The Nimble pipeline ID.' This clarifies that the ID is a Nimble-specific identifier, adding minimal meaning beyond the schema's string type. It is helpful but not rich in detail.
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: 'Delete a deal pipeline by ID.' It names the specific resource (deal pipeline), the method (by ID), and distinguishes from sibling tools like archive_deal_pipeline by calling out that all deals will also be deleted.
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 does not explicitly state when to use this tool versus alternatives, but the warning 'All deals in it will also be deleted!' implies a caution that this is a heavy destructive operation. There is no explicit mention of using archive_deal_pipeline for non-destructive archiving, so the guidance is implied rather than 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?
No annotations are provided, so the description carries the burden. It discloses that results are limited to what the requesting user can see, which is a useful behavioral trait. However, it omits other behavioral details such as whether archived pipelines are included, pagination behavior, or any side effects (though listing implies read-only).
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 that gets straight to the point. Every word adds value, and there is no redundancy or filler.
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 simplicity (no parameters) and the presence of an output schema (likely documenting return structure), the description is mostly complete. It states the core behavior and scope. However, it could usefully mention whether it returns all pipelines or if pagination/filtering applies, but this is a minor gap.
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 no parameter detail for the description to add. The baseline for zero parameters is 4, and the description correctly does not invent 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 specifies the verb 'List' and the resource 'contact/lead pipelines', and adds scope 'visible to the requesting user'. This distinguishes it from sibling tools like list_deal_pipelines, which operate on deal pipelines rather than contact pipelines.
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 retrieving contact/lead pipelines and notes visibility scoping, but it does not explicitly state when to choose this tool over alternatives or provide exclusions. Usability is implied by the clear resource reference, but no explicit guidance is 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 full burden. It adds the behavioral detail of 'most-overdue first', but does not disclose what 'overdue' means, authentication needs, response format, or pagination 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 extremely concise: one lead sentence and two bullet-style parameter explanations. No filler or redundant content.
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 simple read-only list tool with an output schema present, the description covers the core purpose, ordering, and parameters. It lacks explicit sibling differentiation and behavioral caveats, but remains fairly complete given the tool's low complexity.
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 0%, so the description must explain parameters. It does so clearly: deal_id is 'The Nimble deal ID' and limit is 'Max activities to return', adding meaningful semantics beyond the bare schema titles.
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 verb 'List' and the specific resource 'a deal's overdue activities', with an additional ordering trait 'most-overdue first'. It distinguishes from siblings like list_activities by being deal-scoped and overdue-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 context is implied: use when you need overdue activities for a specific deal. However, it does not explicitly mention alternatives, when-not to use, or how it differs from the sibling list_activities.
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 full burden. The verb 'list' implies a read-only operation, but no explicit statement about side effects, required permissions, or potential limitations is made. It conveys the basic behavior but lacks depth.
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 one concise sentence, immediately front-loaded with the key verb and object. It contains no redundant details and is easy to scan.
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?
The tool is a simple list operation with no parameters and an output schema (which covers return values). The description captures the essential scope ('all deal pipelines and their stages') and is complete for this low-complexity tool, though it could have explicitly noted that it lists all without filtering.
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?
There are zero parameters, so the baseline for this dimension is 4. The description correctly focuses on the tool's function rather than repeating schema information, which is empty.
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 ('List') and the resource ('all deal pipelines and their stages'), and the use of 'all' distinguishes it from single-pipeline retrieval tools like get_deal_pipeline. This fully clarifies 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies to use this tool when you need all pipelines and their stages, but it does not explicitly mention alternatives or provide exclusions. Sibling tools (e.g., get_deal_pipeline) exist, but the description doesn't contrast with them.
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 pagination behavior (per_page and page) and implies a read-only action via the verb 'List.' However, it does not provide additional behavioral context such as sorting, ordering, or any potential side effects, leaving gaps.
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 starts with a concise purpose statement and then provides a structured Args list. There is no unnecessary text, and the content is well-organized for quick reading.
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 simple paginated list tool, the description covers the core purpose and all parameters. An output schema is present, so return values need not be described. It lacks explicit usage guidance but is otherwise sufficiently complete for the tool's complexity.
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 0%, and the description compensates with an Args block that explains each parameter purpose: contact_id is a Nimble contact ID, per_page controls results per page, and page indicates page number. This adds meaning beyond the bare schema titles, though it redundantly repeats the default values already present in 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 a specific verb+resource+scope: 'List notes for a specific contact.' This distinguishes it from sibling tools like get_note (single note retrieval) and create_note/update_note (write operations).
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?
Usage is implied by the wording ('for a specific contact'), but there is no explicit guidance on when to use this tool versus alternatives such as get_note or list_activities. The description does not mention any exclusions or alternative tool recommendations.
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?
Annotations are absent, so the description carries the burden. It discloses the query format, operators, and an example, which is useful behavioral context. However, it does not explicitly state read-only behavior, error handling, authentication needs, or rate limits. As a search operation, read-only is implied but not stated.
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 structured with an Args section and a clear breakdown of each parameter. The example is valuable and not wasted. It is somewhat lengthy but every line serves a purpose, earning a high score without perfect brevity.
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 tool with a complex query syntax and no annotations, the description covers all parameters and provides essential operational details. The output schema exists, so return values need no explanation. It could mention error cases or performance implications, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by detailing query_json with format, operators, and a concrete example, plus clarifying per_page and page with default values. This adds substantial meaning beyond the raw schema, making the parameters self-documenting.
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's function: 'Search contacts with an advanced NSE query.' The verb is specific ('search'), the resource is defined ('contacts'), and the 'advanced NSE query' distinguishes it from simpler tools like list_contacts or get_contacts_by_ids.
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 the tool (when you need advanced search), but it does not explicitly state alternatives or exclusions, such as 'use list_contacts for simple listing' or 'use get_contact for a single contact.' The usage context is clear from the parameters 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.
Behavior3/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 adds useful details: note_preview defaults to the first 100 characters if left empty, and contact_ids must be comma-separated and limited to 1-10. However, it does not disclose whether the update replaces the entire note or just provided fields, nor any authorization or error conditions, so transparency is partial.
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 compact and well-structured: a one-sentence purpose followed by a clean Args block. Every line conveys necessary information, with the main verb front-loaded and no filler content.
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?
An output schema exists, so return values are not the description's responsibility. All four parameters are explained with meaningful constraints and defaults, and the core update behavior is conveyed. The only gap is missing usage guidance and edge-case handling, but for a typical update tool, the description is sufficiently complete for correct invocation.
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 no descriptions for any parameters (0% coverage), so the description fully compensates by explaining each one: note_id as the Nimble ID, contact_ids as comma-separated IDs with a count limit, note as the full updated text, and note_preview with its default derivation rule. This exceeds the bare schema and gives the agent actionable 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 'Update an existing note,' using a specific verb+resource structure that distinguishes it from siblings like create_note, get_note, and delete_note. The word 'existing' explicitly limits scope to current notes, eliminating 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?
Usage is implied through the verb 'update' and the word 'existing,' but no explicit guidance is given regarding when to use this tool versus create_note or other sibling note tools. The description does not mention alternatives or exclusions, leaving the agent to infer that an existing note_id is required.
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 full burden. It discloses the tag limit ('max 5 on creation') and field applicability (e.g., company_name required for company records), but it does not mention permissions, idempotency, or what happens on validation failure. The provided details are useful but not comprehensive.
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 and front-loaded with the purpose, followed by an ordered Args list where each line is a meaningful parameter explanation. There is no wasted text, and the structure is easy to parse.
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?
The description covers the parameters and conditional requirements well, and an output schema exists so return details are not needed. It lacks explicit guidance on when to use this versus sibling tools, but for a 9-parameter creation tool with a required record_type, the provided information is largely sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: record_type values, conditional name fields, email/phone modifier enumerations, and tag limits. This adds significant meaning beyond the bare schema titles.
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 new contact (person or company)' with a clear verb and resource, and the parenthetical distinguishes contact creation from other creates like create_note or create_deal. This 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 when a new contact needs to be created, and the 'person or company' distinction provides some context. However, it does not explicitly mention when to use this tool versus update_contact or delete_contact, nor does it offer exclusions or alternative tool references.
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 adds 'with all fields and tags,' which clarifies the return content. However, it does not discuss error handling, authentication requirements, or rate limits. For a simple read operation, this is adequate but not rich, scoring a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two concise sentences: the core purpose is front-loaded, and the parameter documentation is compact and directly under 'Args.' Every word earns its place with no redundancy.
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 low complexity (one parameter) and the presence of an output schema, the description is nearly complete. It covers the essential input semantics and operation scope. It misses explicit usage guidance, but for a single-ID get with no nested objects, the combination of name, description, schema, and output schema suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter, but the description explicitly documents 'contact_id: The Nimble contact ID,' providing the missing semantics. This fully compensates for the schema gap, giving the agent the necessary meaning for the parameter.
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 'Get a single contact by ID with all fields and tags,' specifying the action (get), resource (contact), and scope (single by ID). This distinguishes it from sibling tools like list_contacts and get_contacts_by_ids, which retrieve multiple contacts or search.
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 retrieving one contact by ID, but it does not explicitly mention alternatives or when not to use it. Siblings such as get_contacts_by_ids, list_contacts, and search_contacts exist, yet no guidance is provided on choosing among them. Usage is implied by the wording rather than explicitly 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 full burden of behavioral disclosure. It transparently states that it returns complete schema including custom fields, types, and modifiers, implying a read-only operation. However, it does not discuss permissions, potential response sizes, or any other side effects, though for a simple listing tool these omissions are not critical.
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 and well-structured, with two sentences that front-load the core action and then add valuable specifics. Every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters) and the presence of an output schema, the description is complete. It clearly states what is returned and covers the metadata content, leaving no significant gaps for the agent to infer.
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 takes zero parameters, so schema coverage is trivially 100%. The description does not need to explain any parameters, and the baseline score of 4 for zero-parameter tools is appropriate. No additional parameter context is required.
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 lists contact field metadata, specifically enumerating tabs, groups, and fields. This precise verb-resource pairing distinguishes it from sibling tools like list_contacts or get_contact, and the additional detail about custom fields and types reinforces its unique purpose.
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 retrieving the complete schema of contact fields, which is useful for understanding available fields before working with contacts. However, it does not explicitly mention when to use this tool versus alternatives such as create_contact_field or list_contacts, nor does it state any exclusions or prerequisites.
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 adds behavioral details like sort spec format and limit per stage. The operation is inherently read-only ('List') and the description doesn't mention side effects, auth, or pagination. It provides some value but not rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear summary line followed by a concise Args block. No filler or redundancy. All sentences contribute value.
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 simplicity (one required param, output schema exists), the description covers the core purpose and parameter meanings. It lacks some behavioral details like stage ordering, but overall it is sufficient for an agent to select and invoke correctly.
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 0%, so the description must compensate. It explains all three parameters: pipeline_id as 'Nimble pipeline ID', sort as '"<field>:<order>"', and limit as 'Max deals per stage'. This goes beyond the schema, though sort fields/order values remain implicit.
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 'List a pipeline's deals grouped by stage' — a specific verb, resource, and grouping behavior. This clearly distinguishes it from sibling tools like list_deals (global deals) and list_pipeline_deals_by_owner (grouped by owner).
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 a clear use case: when you need a pipeline's deals organized by stage. It provides enough context (pipeline_id, grouping, per-stage limit) but does not explicitly name alternatives or exclusions. This is 'clear context, no exclusions' per the rubric.
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 does add valuable constraints (required deal name field, probability requirement, example format) and implies a write operation. However, it does not disclose permissions, side effects, or how existing data may be affected, which a mutation tool with no annotations should ideally mention.
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 well-structured with a clear purpose statement and an Args list. Every line provides essential information without unnecessary fluff, making it easy to scan and follow.
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?
The description covers all parameters and key constraints, which is sufficient for invoking the tool correctly. It could be slightly more complete by mentioning how to obtain pipeline_id/stage_id or field IDs, but these are discoverable through sibling tools and not strictly necessary for execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description thoroughly explains all six parameters, including formats, required values, and an example for fields_values_json. It compensates fully for the lack of schema documentation.
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 identifies the operation as creating a new deal in Nimble CRM (deals_v2), with a specific verb and resource. This distinguishes it from sibling tools like update_deal, get_deal, and delete_deal.
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 establishes a clear context for creating a new deal, which is implicitly distinct from update/delete operations. However, it does not explicitly mention when to avoid using it or suggest alternative tools such as update_deal for modifying existing deals.
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?
With no annotations, the description carries the burden. It discloses the destructive nature and explains the preflight_checks parameter's behavior, which is key to preventing data loss. However, it stops short of detailing consequences when preflight_checks is false, or mentioning irreversibility beyond the word 'delete'.
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?
Extremely concise: one opening sentence plus an Args block. No redundant info. Every sentence adds value.
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 simple deletion tool with an output schema, the description is nearly complete. It covers the core operation and the main behavioral switch, but could mention what happens on deletion when preflight_checks is false (e.g., contacts lose the field data).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description's Args section fully compensates by explaining both field_id and preflight_checks, including the critical conditional behavior of preflight_checks.
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 ('Delete') and the resource ('custom contact field'), distinguishing it from sibling delete tools like delete_contact and delete_deal_tag. The phrase 'custom contact field' 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 provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The purpose implies usage but doesn't discuss scenarios or when not to use it.
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 full burden. It discloses a permission requirement, parameter precedence (query_json ignores record_type), and the preflight_checks behavior. However, it does not mention whether the deletion is permanent, what happens to related data, or any response format—leaving some behavioral gaps for a destructive 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 compact and well-structured: a one-sentence summary, a permission note, and a clear Args list. Every sentence provides necessary information without redundancy. The main purpose is front-loaded, making it easy to scan.
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 tool with 4 parameters and no schema descriptions, the description covers the essential context: purpose, permission, parameter semantics, and a key behavioral nuance. The presence of an output schema covers return-value expectations. It lacks some details like potential side effects or explicit comparison to sibling delete tools, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates fully by explaining every parameter in the 'Args' section. It adds meaning beyond the schema: query_json is a JSON-encoded advanced query, keyword is comma-separated, record_type has specific allowed values, and preflight_checks verifies editability. This is exactly what the schema lacks.
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 opens with 'Bulk-delete contacts matching an advanced query or keyword list,' which clearly states the verb, resource, and scope. It distinguishes this from siblings like delete_contact by emphasizing bulk deletion via query or keywords, making the tool's 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 provides clear context for when to use (bulk delete by query or keywords) and states a prerequisite ('Requires bulk delete permission'). However, it does not explicitly name alternatives or state when NOT to use this tool in favor of delete_contact or delete_contacts, so it stops short of full exclusion 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?
With no annotations provided, the description carries the full burden of disclosure. It states that the tool requires an 'authenticated' user and retrieves info/account details, which is the core behavior. However, it does not mention any potential limitations (e.g., error conditions, rate limits) or that it is a read-only operation beyond the word 'Get'.
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, focused sentence that is front-loaded with the action ('Get') and resource. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an extremely simple tool with no parameters and an output schema already provided. The description successfully conveys the essential purpose and scope of the operation. There are no missing elements that would hinder correct invocation or use.
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 schema coverage is trivially 100%. The description adds no parameter details because none exist. Baseline for 0 params is 4, and the description does not need to compensate for any undocumented 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 uses the specific verb 'Get' and clearly identifies the resource: 'current authenticated Nimble user info and account details.' It unambiguously distinguishes this tool from all siblings, none of which target the authenticated user's own profile.
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 clearly implies when to use this tool: whenever the agent needs the current user's identity or account-level information. Since no sibling tool covers this functionality, explicit exclusions or alternatives are unnecessary, but the context is clear.
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?
Despite having no annotations, the description discloses important behavioral details: fields_values_json sends an empty list to clear a field, tags replaces existing tags, and pipeline/stage/owner parameters move/reassign the deal. This goes beyond simply stating 'update' and provides concrete side effects. Minor omissions like whether unspecified fields remain unchanged are left implicit, but overall transparency is strong.
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 opening sentence followed by a succinct bullet-style list of parameters, each on its own line. Every sentence is informative with no fluff or repetition. The format is easy to parse and front-loads the primary purpose before diving into details.
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?
The description covers all six parameters and their behavioral semantics, which is comprehensive given the tool's complexity. The presence of an output schema reduces the need to describe return values. It could add a note on partial update behavior (e.g., unspecified fields remain unchanged), but the current level is sufficient 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully compensates by explaining every parameter in detail: deal_id is the Nimble ID, fields_values_json has a specific JSON structure with clear instructions for clearing fields, pipeline_id/stage_id move the deal, owner_id reassigns, and tags replaces the list. This is exceptional parameter documentation.
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 opens with 'Update an existing deal,' which clearly identifies the verb (update), resource (deal), and scope (existing). This directly distinguishes it from siblings like create_deal and delete_deal. The parameter list further clarifies the kinds of updates supported.
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 by being an update tool; an agent can infer it is for modifying existing deals. However, there is no explicit guidance on when to choose this over related tools (e.g., use it instead of create_deal for existing records) or any exclusions. The context is clear but not fully spelled out.
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 carries the burden. It discloses that the tool returns only IDs and is faster than a full listing, and it gives a behavioral hint about 'keyword' being a 'simple search across indexed fields.' It does not discuss edge cases, sorting, or exact output formatting, but the output schema covers return structure, making this adequate for a simple read 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 front-loaded with the core purpose and then presents parameters in a clean, scannable list. Every line earns its place; there is no fluff or repetition of schema trivia beyond what is useful.
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 simple listing tool with an output schema, the description sufficiently covers purpose, usage context, and all parameters. It could be slightly more complete by explicitly naming sibling alternatives or noting that all parameters are optional, but the existing information is enough for an agent to use it effectively.
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 no descriptions (0% coverage), so the description must compensate. It does so by explaining each parameter: record_type with its allowed values, keyword as a simple indexed-field search, per_page with default, and page with a start value. This adds real meaning beyond the bare parameter names, though the explanations are concise rather than exhaustive.
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 opens with a specific verb and resource ('List contact IDs only') and explicitly contrasts with 'a full contact listing,' which clearly distinguishes it from the sibling tool list_contacts. The purpose is immediately obvious and unique.
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 phrase 'faster than a full contact listing' clearly implies this tool is the choice when only IDs are needed, offering clear context. However, it does not explicitly name alternatives such as list_contacts or search_contacts, nor provide when-not-to-use guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 behavior. It explains the replace vs. merge semantics, how to remove values by setting an empty list, and provides a concrete example of the fields_json format. This gives meaningful insight into the tool's behavior, though it does not mention irreversibility or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an 'Args' section, parameters clearly listed, and a concise example. Every sentence adds value, explaining the JSON format and edge cases (emptying a field). No fluff or repetition is present, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (per context signals), the description need not explain return values. It comprehensively covers all input parameters, their formats, and behavioral nuances such as replace vs. merge and removal of values. This is sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all three parameters: contact_id is identified as the Nimble contact ID, fields_json is explained with a format and example, and replace is defined with true/false behavior. This significantly exceeds the schema's basic type information.
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 an existing contact's fields' with a specific verb and resource. This distinguishes it from siblings like create_contact, delete_contact, and list_contacts by virtue of the 'update' operation, even though no explicit comparison is made.
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 modifying existing contacts, but does not explicitly state when to use this tool versus alternatives like create_contact or replace_tags. No exclusions or alternative recommendations are provided, leaving the guidance at an implied level.
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?
With no annotations provided, the description carries the transparency burden. It discloses meaningful behavioral details: the 'regular' deletion_method errors if relations block deletion, while 'force' deletes despite relations, and cleanup_email_lists removes matching email list entries. This goes beyond a simple 'delete' statement, though it omits permanence or permission details.
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 succinct and well-structured, beginning with a one-line purpose statement followed by a clean Args block. Every sentence adds value, with no filler or repetition.
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 3-parameter delete tool with no annotations and no schema descriptions, the description covers the essential operational aspects and side effects. An output schema exists, so return value details are not necessary. It is slightly generic regarding error scenarios (e.g., not-found) but the deletion_method explanation covers the main edge case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: contact_id is the Nimble contact ID, deletion_method behavior is defined for 'regular' and 'force', and cleanup_email_lists clarifies the side effect. This adds meaning beyond the bare schema names and types.
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's function with a specific verb and resource: 'Delete a single contact by ID.' It distinguishes itself from sibling tools like delete_contacts (plural) and delete_contacts_by_query by emphasizing 'single' and 'by ID.'
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 appropriate use case through 'single contact by ID,' which contrasts with bulk deletion tools among siblings. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 side effects. It explicitly states the destructive behavior: 'tags not in the list will be REMOVED.' This goes beyond a simple 'replace' and warns the agent about data loss. The 'WARNING' formatting emphasizes the irreversible nature, which is exactly the kind of behavioral context needed when annotations are absent.
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 and effectively structured: a one-line summary, a highlighted warning, then a brief Args section. Every sentence provides necessary information without redundancy. The front-loaded warning ensures the agent notices the destructive behavior immediately, and the layout separates operational guidance from parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, an output schema, and no annotations, the description covers all essential aspects: purpose, destructive behavior, parameter semantics, and usage strategy. There is no missing information that would prevent an agent from using the tool correctly. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters, so the description must compensate. It clearly defines contact_id as 'The Nimble contact ID' and tags as a 'Comma-separated list of tags to set.' This adds crucial format and semantics that the schema lacks (e.g., tags are comma-separated). The additional guidance on constructing the tag list for an add operation further enriches parameter meaning.
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 opens with 'Replace all tags on a contact,' which uses a specific verb ('replace'), identifies the resource ('tags on a contact'), and clearly conveys the operation's scope ('all'). This distinguishes it from sibling tools like delete_deal_tag or rename_deal_tag, which target deal tags, while this tool is explicitly for contact tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with a prominent WARNING: it is a full replace that removes unspecified tags. It also gives a concrete alternative strategy for adding a tag — first retrieve current tags via get_contact, then include all existing plus the new one. This clearly instructs the agent on safe usage and distinguishes it from a typical 'add' operation.
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:

[![mcp-nimble-crm MCP server](https://glama.ai/mcp/servers/meshachjackson/mcp-nimble-crm/badges/card.svg)](https://glama.ai/mcp/servers/meshachjackson/mcp-nimble-crm)

Score Badge

Copy to your README.md:

[![mcp-nimble-crm MCP server](https://glama.ai/mcp/servers/meshachjackson/mcp-nimble-crm/badges/score.svg)](https://glama.ai/mcp/servers/meshachjackson/mcp-nimble-crm)

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/meshachjackson/mcp-nimble-crm'

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