Server Quality Checklist

Tool Scores

• create-upnify-prospectC
  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 'creates' without detailing behavioral traits. It lacks information on permissions needed, whether the operation is idempotent, what happens on duplicate emails, or the response format, leaving critical 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, 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 mutation tool with 14 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like error handling, success indicators, or integration context, leaving the agent with significant uncertainty about how to use it effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all 14 parameters. The description adds no additional parameter semantics beyond implying prospect creation, which aligns with the schema but doesn't provide extra value like usage examples or 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 states the action ('Create a new prospect') and resource ('in Upnify CRM'), making the purpose unambiguous. It distinguishes from siblings like 'create-upnify-opportunity' by specifying the prospect entity, though it doesn't explicitly contrast them.

  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. While it's implied for prospect creation, there's no mention of prerequisites, dependencies, or when to choose this over similar tools like 'search-upnify-contacts' for existing records.

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

• get-upnify-activity-reportC
  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 what the tool does but doesn't describe important behavioral aspects: whether this is a read-only operation, what format the report returns, whether it requires specific permissions, or if there are rate limits. For a reporting tool with zero annotation coverage, this is insufficient.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a tool with two well-documented parameters and follows a clear subject-verb-object structure.

  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 reporting tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the activity report contains, what format it returns, or any behavioral constraints. The agent would need to guess about the output structure and operational characteristics.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters having detailed enum descriptions. The description adds minimal value beyond the schema, only mentioning 'by group or executive and period' which is already covered in the schema's parameter descriptions. Baseline 3 is appropriate when schema documentation is comprehensive.

  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 'Get' and resource 'activity report from Upnify', with specific scoping 'by group or executive and period'. It distinguishes from some siblings like 'get-upnify-conversion-report' by specifying the report type, but doesn't explicitly differentiate from all reporting siblings like 'get-upnify-sales-report' beyond the report name.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives is provided. The description mentions the grouping options but doesn't explain when to choose group vs executive grouping, nor when to use this activity report versus other reporting tools like 'get-upnify-conversion-report' or 'get-upnify-sales-report'.

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

• get-upnify-conversion-reportC
  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 but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, requires authentication, has rate limits, returns paginated data, or what the output format looks like. For a reporting tool with zero annotation coverage, this is inadequate.

  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?

  Single sentence, front-loaded with the core purpose, efficiently listing key dimensions without redundancy. Every word earns its place, making it easy to scan and understand 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 reporting tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on output format, data scope, error handling, or behavioral traits. While concise, it doesn't compensate for the missing structured information needed for reliable agent 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%, with all parameters well-documented in the schema (agrupacion, periodo, situacion). The description adds minimal value by listing grouping options and period, but doesn't provide additional context beyond what's in the schema. Baseline 3 is appropriate when 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 ('Get conversion report') and resource ('from Upnify'), with specific grouping dimensions listed (group, executive, origin, region) and period. It distinguishes from siblings like 'get-upnify-activity-report' and 'get-upnify-sales-report' by focusing on conversion metrics, though it doesn't explicitly contrast them.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives like 'get-upnify-sales-report' or 'get-upnify-activity-report'. The description implies usage for conversion analysis by group/period but lacks context on prerequisites, exclusions, or comparisons to sibling tools.

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

• get-upnify-sales-reportC
  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 mentions 'customizable grouping, period, year and tax options' which hints at configuration, but doesn't describe what the tool actually returns (e.g., format, structure, pagination), whether it's a read-only operation, potential rate limits, authentication requirements, or data freshness. For a reporting tool with zero annotation coverage, this is inadequate.

  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 immediately communicates the core functionality. Every word earns its place—'Get sales report' establishes the action, 'from Upnify' specifies the source, and 'with customizable grouping, period, year and tax options' highlights key parameters without 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?

  Given the tool's complexity (4 required parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain what the report output looks like, how data is structured, whether there are limitations (e.g., date ranges, access permissions), or how it differs from sibling report tools. For a reporting tool with multiple configuration options, more context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, with detailed enum descriptions for all parameters. The description adds minimal value beyond the schema, only listing the four parameter categories without providing additional context about how they interact or affect the report output. This meets the baseline of 3 when schema coverage is high.

  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 ('Get') and resource ('sales report from Upnify'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'get-upnify-activity-report' or 'get-upnify-conversion-report' by specifying it's for sales data. However, it doesn't explicitly contrast with all siblings, such as 'search-upnify-contacts'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this sales report is appropriate compared to other report tools (e.g., activity or conversion reports) or when to use search tools. There's no context about prerequisites, data freshness, or limitations.

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

• create-upnify-opportunityB
  3.1/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 states this is a creation operation but doesn't cover critical aspects like required permissions, whether this is a write/mutation tool, potential side effects, error conditions, or response format. The mention of 'requires tkProspecto from search' hints at a dependency but doesn't fully explain behavioral constraints.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core purpose and includes the key prerequisite. There's no wasted verbiage, though it could be slightly more structured by separating the prerequisite into a second sentence for clarity.

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

  Completeness2/5

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

  For a creation tool with no annotations and no output schema, the description is insufficient. It lacks information about what happens after creation (success response, error handling), permissions needed, system constraints, or how this tool fits into broader workflows. The prerequisite hint helps but doesn't compensate for missing behavioral and output context.

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

  Parameters3/5

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

  The schema description coverage is 100%, with each parameter well-documented in the schema itself (e.g., commission as decimal, prospect token from search). The description adds minimal value beyond the schema by mentioning the tkProspecto requirement, but doesn't provide additional context about parameter relationships, validation rules, or business logic. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Create a new opportunity') and target resource ('for a prospect in Upnify CRM'), which distinguishes it from sibling tools like create-upnify-prospect or create-upnify-reminder. However, it doesn't specify what an 'opportunity' entails in the CRM context, leaving some ambiguity about the exact nature of the resource being created.

  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 guidance by mentioning the prerequisite 'requires tkProspecto from search', which suggests this tool should be used after obtaining a prospect token via search-upnify-contacts. However, it lacks explicit when-to-use rules, alternatives (e.g., vs. updating opportunities), or exclusions, leaving the agent to infer context from the parameter requirement.

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

• create-upnify-reminderB
  3.1/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. While 'Create a new reminder' implies a write operation, it doesn't specify authentication requirements, rate limits, whether the creation is idempotent, what happens on success/failure, or any side effects. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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 is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple creation tool and front-loads the essential information ('Create a new reminder in Upnify agenda').

  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 creation tool with no annotations and no output schema, the description provides minimal but adequate context about what it does. However, it lacks important details about behavioral aspects (like what gets returned or error conditions) that would be needed for robust agent usage. The 100% schema coverage helps, but the overall context remains 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 schema description coverage is 100%, with all three parameters clearly documented in the input schema. The description adds no additional parameter information beyond what's already in the schema (subject, description, start date/time format). This meets the baseline expectation 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.

  Purpose4/5

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

  The description clearly states the action ('Create a new reminder') and the resource ('in Upnify agenda'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (e.g., create-upnify-opportunity, create-upnify-prospect), which all create different types of Upnify entities but share similar naming patterns.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this tool is appropriate versus other creation tools (like create-upnify-opportunity), or any contextual constraints. The agent must infer usage from the tool name alone.

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

• get-upnify-pending-paymentsB
  3.1/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. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the report comes in. The mention of 'customizable grouping and period options' hints at configuration but doesn't explain behavioral implications.

  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 communicates the core purpose without unnecessary words. It's appropriately sized for a tool with two well-documented parameters and gets straight to the point with zero wasted verbiage.

  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 read-only reporting tool with two well-documented parameters and no output schema, the description is minimally adequate. It identifies what the tool does but lacks important context about when to use it versus sibling tools and doesn't describe the report format or any behavioral constraints that would be important 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.

  Parameters3/5

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

  Schema description coverage is 100% with both parameters fully documented in the schema itself. The description mentions 'customizable grouping and period options' which aligns with the schema parameters but adds no additional semantic context beyond what's already in the parameter descriptions. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Get pending payments report') and source ('from Upnify'), which is specific and unambiguous. However, it doesn't distinguish this tool from its sibling tools like 'get-upnify-activity-report' or 'get-upnify-sales-report' beyond mentioning 'pending payments' - the distinction 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?

  The description provides no guidance on when to use this tool versus alternatives. With multiple sibling reporting tools (activity, conversion, sales reports), there's no indication of what makes 'pending payments report' distinct or when it's the appropriate choice over other reporting tools.

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

• search-upnify-contactsB
  3.1/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 states the search functionality but lacks details on permissions, rate limits, pagination, or response format. 'Search for contacts' implies read-only, but no explicit safety or operational context 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 a single, efficient sentence with zero waste. It front-loads the core purpose and includes essential search criteria, making it easy to parse quickly.

  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 search tool with 2 parameters and 100% schema coverage, the description is adequate but incomplete. No output schema exists, and with no annotations, it should ideally mention response structure or limitations. It covers the basics but lacks depth for full agent understanding.

  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 both parameters thoroughly. The description adds minimal value by mentioning search fields (name, email, phone) which aligns with 'buscar', 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 action ('Search for contacts') and the resource ('contacts in Upnify'), specifying the searchable fields (name, email, phone). It distinguishes from siblings by focusing on search rather than creation or reporting, though it doesn't explicitly name alternatives for similar search functions.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for searching contacts, or differentiate from potential sibling search tools (none listed, but no explicit comparison).

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