Server Quality Checklist

Tool Scores

• create_personC
  2.9/5.0
  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 states this is a creation operation but doesn't mention important behavioral aspects: whether this requires specific permissions, what happens on duplicate entries, whether the operation is idempotent, what the response contains, or any rate limits. The description is minimal and leaves critical behavioral questions unanswered.

  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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a creation tool and gets straight to the point with no unnecessary elaboration.

  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 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (return values, success indicators), doesn't mention error conditions, and provides no context about Copper CRM's specific behavior for person creation. The description leaves too many open questions for effective tool use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation entirely through the schema, with no value added by the description.

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

  Purpose4/5

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

  The description clearly states the action ('Create') and resource ('new person/contact in Copper CRM'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'update_person' or 'get_person' beyond the obvious creation vs. update/retrieval distinction.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'update_person' or 'search_people'. There's no mention of prerequisites (e.g., whether the person must not already exist), nor any context about when creation is appropriate versus updating existing records.

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

• get_personC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only states it's a read operation ('Get'). It doesn't disclose behavioral traits such as error handling, authentication needs, rate limits, or what 'full details' entails. This leaves gaps for a tool that likely returns structured data.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

  Completeness2/5

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

  For a read tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'full details' includes, potential response formats, or error cases. Given the context of sibling tools like 'update_person', more behavioral context is needed for effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents the 'person_id' parameter. The description adds minimal value by implying it fetches details for a specific ID, but doesn't provide additional context like ID format or examples beyond the schema.

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

  Purpose4/5

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

  The description clearly states the action ('Get full details') and resource ('Copper contact'), making the purpose understandable. It specifies retrieval by ID, which distinguishes it from search/list siblings, but doesn't explicitly contrast with 'search_people' or 'list_activities' for contact 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?

  No guidance is provided on when to use this tool versus alternatives like 'search_people' or 'update_person'. The description implies it's for fetching details when you have an ID, but it doesn't state prerequisites, exclusions, or compare to sibling tools.

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

• search_companiesC
  2.9/5.0
  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 mentions the search action and return type but omits critical details like pagination behavior (implied by parameters but not described), rate limits, authentication needs, error handling, or whether it's read-only. This leaves significant gaps for an agent.

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

  Conciseness5/5

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

  The description is two concise sentences with zero waste. It's front-loaded with the core purpose and efficiently states the outcome. Every word earns its place, making it easy to parse.

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

  Completeness2/5

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

  Given the tool has no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., pagination details, safety profile) and output specifics, which are crucial for a search tool with parameters. The description does not compensate for these gaps adequately.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents the three parameters. The description adds no additional meaning beyond implying 'name' is the search key, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 ('Search') and target resource ('Copper companies by name'), with the outcome ('Returns matching company records'). It's specific but doesn't differentiate from sibling tools like 'search_people' beyond the resource type, which is implied but not explicit.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, when to prefer this over other search or list tools, or any exclusions. It's a basic functional statement without usage context.

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

• list_opportunitiesB
  3.2/5.0
  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 mentions the search functionality and return fields but doesn't address important behaviors like pagination (implied by page parameters but not explained), rate limits, authentication requirements, error conditions, or whether this is a read-only operation. The description provides basic functional context but misses key operational details.

  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 appropriately concise with two sentences that efficiently convey core functionality. The first sentence covers purpose and optional filtering, the second specifies return fields. No wasted words, though it could be slightly more structured for clarity.

  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 search tool with 5 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate basic context but has significant gaps. It explains what the tool does and what it returns, but doesn't address pagination behavior, result limitations, error handling, or how results are structured. The absence of output schema increases the need for more complete behavioral description.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema - it mentions optional filtering by company or person (which the schema covers) and implies search functionality for the 'name' parameter. No additional syntax, format details, or constraints beyond what the schema provides.

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

  Purpose4/5

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

  The description clearly states the tool searches Copper opportunities (deals) and returns specific fields (deal name, value, status, pipeline stage). It uses specific verbs ('search', 'returns') and identifies the resource ('opportunities/deals'). However, it doesn't explicitly differentiate from sibling tools like 'search_companies' or 'search_people' beyond mentioning optional filtering by company/person.

  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 searching opportunities with optional company/person filtering, but doesn't provide explicit guidance on when to use this versus alternatives like 'search_companies' or 'search_people'. No when-not-to-use scenarios or prerequisites are mentioned.

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

• search_peopleB
  3.3/5.0
  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 mentions the search functionality and return format (person records with IDs), but doesn't describe pagination behavior (implied by page_size/page_number parameters), rate limits, authentication requirements, error conditions, or whether this is a read-only operation. The description adds minimal behavioral context beyond the basic function.

  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 - just one sentence that efficiently communicates the search scope, return format, and integration purpose. Every word earns its place with zero redundancy. The structure is front-loaded with the core functionality.

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

  Completeness3/5

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

  For a search tool with 5 parameters, 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and integration hint but lacks behavioral details (pagination, errors, limits) and doesn't describe the return format beyond 'person records with IDs'. Given the complexity and missing structured data, it should provide more operational context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema descriptions. It mentions the searchable fields (name, email, phone) which aligns with parameter names but provides no extra context about how searches work (exact vs partial matching, case sensitivity, etc.).

  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 purpose: searching Copper contacts by specific fields (name, email, phone) and returning person records. It distinguishes from siblings like 'get_person' (singular retrieval) and 'search_companies' (different entity type). However, it doesn't explicitly differentiate from 'list_activities' or 'list_opportunities' which are different resource types.

  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 implied usage context by mentioning the returned IDs are 'for use in create_activity', suggesting integration with that specific sibling tool. However, it doesn't explicitly state when to use this versus alternatives like 'get_person' (for known IDs) or 'search_companies' (for different entity). No guidance on when NOT to use this tool is provided.

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

• update_personB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses that updates are partial (only include fields to change) and that tags replace existing ones, which are useful behavioral traits. However, it misses critical details like authentication needs, error handling, or whether changes are reversible.

  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 appropriately sized with two sentences that are front-loaded and efficient. The first sentence states the purpose, and the second adds useful context about field behavior, with 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 mutation tool with no annotations and no output schema, the description is moderately complete. It covers partial updates and field specifics, but lacks information on return values, error cases, or system constraints like rate limits, leaving gaps for an AI agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters well. The description adds minimal value by clarifying the 'details' field corresponds to the 'About' section in the UI, but doesn't provide additional syntax or format details 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 updates an existing person in Copper CRM, specifying it's for contacts. It distinguishes from create_person by focusing on updates, but doesn't explicitly contrast with other sibling tools like get_person or search_people.

  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 contacts and mentions to 'only include fields you want to change,' which provides some guidance. However, it lacks explicit when-to-use vs. alternatives (e.g., create_person for new contacts, get_person for reading) or prerequisites like required permissions.

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

• create_activityA
  3.9/5.0
  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 mentions logging an activity but doesn't disclose behavioral traits like whether this is a write operation (implied by 'Log'), potential side effects, authentication needs, error handling, or response format. For a mutation tool with zero annotation coverage, 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.

  Conciseness5/5

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

  The description is front-loaded with the core purpose in the first sentence, and the second sentence provides essential usage guidance without redundancy. Every sentence earns its place, making it appropriately sized and efficient.

  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 complexity (a mutation with 5 parameters) and no annotations or output schema, the description is incomplete. It covers purpose and usage well but lacks behavioral context (e.g., what happens on success/failure) and output details. It's adequate as a minimum viable description but has clear gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by hinting at the need to use list_activity_types for activity_type_id and specifying plain text for details, but it doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  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 ('Log an activity') and the target resource ('against a Copper person or company'), with examples of activity types. It distinguishes from siblings like list_activities (which retrieves) and create_person (which creates a different entity).

  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?

  It explicitly provides when-to-use guidance by directing the user to 'Use list_activity_types first to get the correct activity_type_id,' which is a prerequisite step. This distinguishes it from tools like list_activities that don't require such preparation.

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

• list_activitiesA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses useful behavioral traits: what gets returned ('Returns resolved parent names'), what's excluded by default ('Excludes system activities'), and pagination behavior is implied through parameters. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'Search' implies it).

  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 perfectly concise with three information-dense sentences. The first sentence establishes purpose and scope, the second explains filtering capabilities, and the third covers return values and exclusions. Every sentence earns its place with zero 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 search/list tool with 7 parameters, 100% schema coverage, but no annotations and no output schema, the description is adequate but has gaps. It covers purpose, filtering, exclusions, and return values, but doesn't address authentication, error handling, rate limits, or provide examples of the output format. The lack of output schema means the description should ideally say more about what the response looks like.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds marginal value by mentioning the filtering capabilities ('Filter by parent record, activity type, or date range') and the default exclusion behavior, but doesn't provide additional parameter semantics beyond what's in the 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 clearly states the verb ('Search') and resource ('Copper activities') with specific examples of what activities include ('meeting notes, calls, emails logged against contacts'). It distinguishes from siblings by focusing on listing/searching activities rather than creating them (create_activity) or managing other entities like people/companies.

  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 about when to use this tool ('Filter by parent record, activity type, or date range') and mentions what it excludes ('Excludes system activities... by default'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for different filtering needs.

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

• list_activity_typesA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses this is a read operation (listing) and mentions the return format (activity_type_id values), but doesn't address behavioral aspects like rate limits, authentication requirements, or whether the list is paginated/filterable.

  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, efficient sentence that front-loads the purpose and includes essential context about the return value's usage. Every word earns its place with no redundancy or unnecessary elaboration.

  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 (0 parameters, no output schema, no annotations), the description is reasonably complete—it explains what the tool does and how its output is used. However, it could be more comprehensive by addressing potential behavioral constraints or explicitly differentiating from similar sibling tools.

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

  Parameters4/5

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

  The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the empty input. The description appropriately doesn't add parameter information, maintaining a baseline score of 4 for zero-parameter tools.

  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 verb ('List') and resource ('all available activity types in Copper'), with specific examples provided (Note, Meeting, Phone Call). However, it doesn't explicitly differentiate from sibling tools like 'list_activities' which might list activity instances rather than activity types.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool by stating it 'Returns activity_type_id values needed for create_activity,' linking it to a specific sibling tool. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'list_activities' for different purposes.

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