Server Quality Checklist

Tool Scores

• get_activityB
  3.1/5.0
  Behavior2/5

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

  Lacking annotations, the description must carry full behavioral burden. It mentions 'recent' (vague time window) and content type ('actions and their results'), but fails to disclose sort order (chronological?), data retention limits, whether returned entries include system vs. user actions, or pagination behavior beyond the limit parameter.

  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?

  Two sentences with zero waste. First sentence establishes operation and scope; second sentence describes return content. Appropriately front-loaded and sized for the tool's complexity.

  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?

  Adequate for a simple 2-parameter read operation, but gaps remain due to missing output schema and annotations. Description mentions what content is returned (actions/results) but omits structural details, time range constraints, or result ordering that would complete the picture.

  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?

  With 100% schema description coverage, the schema already documents both agentId and limit parameters. The description adds context about the agentId being optional ('all agents'), but adds no additional semantics about the limit parameter or parameter interaction that isn't already in 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?

  Uses specific verb 'Get' and resource 'activity log entries' with clear scope ('for an agent or all agents'). Implicitly distinguishes from sibling get_agent_stats by focusing on log entries rather than statistical aggregations, though explicit contrast would strengthen this.

  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?

  Mentions the optional agentId parameter ('for an agent or all agents') but provides no explicit guidance on when to use this versus get_agent_stats, run_agent, or other monitoring tools. No 'when not to use' or prerequisite guidance provided.

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

• get_creditsB
  3.2/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It specifies 'current' data (temporal context) but fails to disclose if this is cached/real-time, whether the operation is safe/read-only, or what format/structure the response takes given no output schema exists.

  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 10-word sentence with no waste. Front-loaded action verb followed by specific data targets. 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?

  Adequate for a zero-parameter read operation, but with no output schema and no annotations, the description should ideally sketch the return structure (objects, currencies, numeric formats) or mention this retrieves aggregated account data versus per-agent data.

  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?

  Zero parameters present, which establishes baseline 4. Description correctly implies no inputs are needed to retrieve account-level credit data.

  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?

  Clear verb 'Get' and specific resources (credit balance, monthly spending cap, usage) are listed. Implicitly distinguishes from sibling agent/product tools by addressing account billing data, though lacks explicit contrast with other 'get_' siblings like get_activity or get_dashboard.

  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 provided on when to invoke versus alternatives (e.g., get_dashboard which might also show usage metrics), nor any prerequisites or conditions mentioned.

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

• get_dashboardB
  3.2/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries full burden. While 'Get' implies a read operation, the description discloses no behavioral traits regarding data freshness (real-time vs cached), permission requirements, performance characteristics for large accounts, or what the overview structure contains beyond the three mentioned entities.

  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 action verb and scope. No redundancy or filler. Every word contributes to understanding the tool's scope and target resources.

  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?

  Adequate for a parameter-less read operation, but gaps remain given the lack of output schema or annotations. Description omits return value structure, whether archived items are included, and how this aggregate view relates to the more specific sibling query 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?

  Input schema contains zero parameters. Per evaluation rules, zero parameters establish a baseline score of 4. The description does not need to compensate for missing parameter documentation.

  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?

  Clear verb ('Get') and resource ('overview of all products, agents, and lead counts'). The scope 'across the entire Swarmix account' implicitly distinguishes this from sibling tools like get_agent_stats (likely per-agent) and list_agents, though explicit contrast with alternatives is not provided.

  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 versus sibling tools like get_activity, get_agent_stats, or get_funnel. No mention of prerequisites or conditions where this overview is most valuable.

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

• run_agentB
  3.2/5.0
  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 adds valuable context that the agent 'will run all enabled actions once,' clarifying scope and singularity. However, it lacks safety information (side effects, idempotency, prerequisites like agent state) that would be necessary for a mutation tool without annotations.

  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 consists of two efficient sentences with no redundant words. The first states the trigger action, and the second clarifies behavioral scope. It is appropriately front-loaded, though slightly more detail on prerequisites or returns could improve utility.

  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 simple schema (1 parameter) and lack of output schema or annotations, the description adequately covers the core action. However, it omits what the tool returns or signals upon completion, which is relevant information when no output schema exists to document the response.

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

  Parameters3/5

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

  Schema coverage is 100%, documenting the agentId parameter as 'The agent ID to run'. The description does not add additional semantics, constraints, or formatting details for the parameter, warranting the baseline score of 3.

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

  Purpose4/5

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

  The description uses specific verbs ('Trigger', 'execution') and identifies the resource ('agent'). However, it does not explicitly distinguish this tool from siblings like pause_agent or resume_agent, which also control agent execution state.

  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 (e.g., when to trigger immediate execution vs. pausing/resuming). The word 'immediate' implies real-time invocation but does not clarify selection criteria among sibling execution controls.

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

• create_productB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It successfully reveals the critical side effect: 'The AI will analyze the website to learn the value proposition and audience.' This explains what happens beyond simple record creation. However, it lacks standard mutation safety details (idempotency, reversibility, error conditions) expected when no annotations exist.

  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?

  Two sentences with zero waste. Front-loaded with the specific action ('Create a new product/business') followed immediately by the purpose clause ('to manage outreach for'). The second sentence efficiently explains the AI analysis mechanism 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?

  Adequate for the parameter complexity (2 simple params), but gaps remain for a creation tool. With no output schema and no annotations, the description should ideally indicate what identifies the created resource or success indicators. The domain parameter is optional (only name is required), but the description implies website analysis always occurs—a subtle 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?

  Input schema has 100% description coverage (baseline 3). The description adds significant value by explaining the behavioral semantics of the 'domain' parameter: it triggers AI analysis of the website to extract 'value proposition and audience.' This context helps the agent understand why to provide a domain and what data format is expected, going beyond the schema's simple 'Website domain' 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?

  Clear specific verb ('Create') and resource ('product/business'). The 'to manage outreach for' clause adds specific context. However, the conflation of 'product/business' creates ambiguity with the sibling tool 'setup_business,' making it unclear which tool handles business-level vs. product-level creation. Distinguishes adequately from other siblings like 'create_agent.'

  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 versus the sibling 'setup_business' (given the description mentions both product and business). No mention of when the optional 'domain' parameter should be provided vs. omitted. Usage is only implied by the phrase 'to manage outreach for.'

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

• create_agentA
  3.5/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Identifies the write operation ('Create') and platform constraints, but omits lifecycle state after creation (configured vs. running), idempotency behavior, or failure modes when productId is invalid.

  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?

  Two tightly focused sentences. First states purpose, second lists requirements/constraints. No redundancy or wasted words despite the null title.

  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?

  Adequate for the input complexity (3 simple parameters) but lacks mention of return values or side effects. Given sibling tools暗示 an agent lifecycle (run/pause/resume), the description should clarify that this only creates configuration rather than activating the 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 has 100% coverage with complete descriptions for all three parameters. Description reinforces the platform enum values and requirement of productId, but adds minimal semantic depth beyond what the schema already provides.

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

  Purpose4/5

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

  Clear verb ('Create') and resource ('AI outreach agent') with scope ('for a specific channel'). Distinct from sibling operations like run_agent, pause_agent, and create_product, though it doesn't explicitly clarify whether the created agent starts in an active or inactive state.

  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?

  States prerequisite ('Requires a product ID') implying dependency on create_product, but lacks explicit workflow guidance (e.g., create_product → create_agent → run_agent) or conditions when NOT to use (e.g., if agent already exists).

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

• list_agentsA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full behavioral disclosure burden and partially succeeds by specifying exactly what data fields are returned (status, platform, last run time). However, it omits critical operational details such as pagination behavior, caching policies, rate limits, or permission requirements necessary for safe invocation.

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

  Conciseness5/5

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

  The description consists of a single efficient sentence that front-loads the action verb 'List' immediately followed by the resource and specific return field details. Every word serves to clarify scope and output, with zero redundancy or wasted clauses.

  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 zero input parameters and no output schema, the description adequately compensates for missing structured metadata by explicitly declaring the three fields returned (status, platform, last run time). While additional behavioral context would improve completeness, the definition is sufficient for a straightforward listing tool.

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

  Parameters4/5

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

  The input schema contains zero parameters, establishing a baseline score of 4 according to evaluation rules. The description appropriately avoids inventing parameter documentation where none exist, maintaining correct alignment with the empty object 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 'List' with clear resource 'AI outreach agents' and enumerates returned fields (status, platform, last run time). While it effectively implies a read-only enumeration distinct from mutation siblings like create_agent or pause_agent, it does not explicitly differentiate from get_agent_stats which may overlap in functionality.

  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 select this tool versus alternatives like get_agent_stats, nor does it mention prerequisites, filtering limitations, or scope constraints. The agent must infer appropriate usage solely from the tool name and the word 'all'.

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

• get_agent_statsA
  3.6/5.0
  Behavior4/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It effectively describes the return value characteristics by listing specific metrics (connections, emails sent, open rates), which substitutes for the missing output schema. However, it lacks safety information (idempotency, error handling) that annotations would typically provide.

  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 the action verb front-loaded. The parenthetical examples add value without verbosity. No wasted words or redundant phrases.

  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 (1 simple parameter, no nested objects) and lack of output schema, the description adequately compensates by listing example return values. It is complete enough for an agent to understand the tool's scope, though error handling details would add value.

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

  Parameters3/5

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

  With 100% schema description coverage for the single agentId parameter, the schema sufficiently documents the input. The description implies the 'specific agent' requirement but does not add semantic details beyond the schema's 'The agent ID' description, meeting the baseline expectation.

  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 verb (Get), resource (performance statistics), and provides concrete examples of returned metrics (connections, emails sent, open rates). However, it does not explicitly differentiate from siblings like get_activity or get_dashboard.

  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 get_activity or list_agents. There are no exclusion criteria or prerequisites mentioned.

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

• pause_agentA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It explains that pausing stops scheduled actions, which is helpful behavioral context. However, it omits reversibility (can it be resumed?), effects on currently executing actions, or idempotency concerns for this state-changing 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?

  Two efficiently structured sentences. The first states the action, the second explains the consequence. No filler or redundancy; every word earns its place.

  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 single-parameter state change tool with 100% schema coverage and no output schema, the description adequately covers the essentials. It could improve by mentioning reversibility via resume_agent, but the current level is acceptable for this complexity tier.

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

  Parameters3/5

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

  Schema coverage is 100%, establishing a baseline of 3. The description adds the constraint that the agent should be 'active,' which provides semantic context beyond the schema's literal 'agent ID to pause.' However, it does not elaborate on the parameter format or validation rules.

  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 verb (Pause), resource (agent), and scope (active), along with the specific effect (stop running scheduled actions). It implicitly distinguishes from siblings like resume_agent and create_agent, though it doesn't explicitly reference them.

  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 explaining the effect (stops scheduled actions), suggesting when to use it. However, it lacks explicit when/when-not guidance or named alternatives like resume_agent for the reverse operation.

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

• search_leadsA
  3.6/5.0
  Behavior3/5

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

  Without annotations, the description carries the full burden. It successfully discloses pagination behavior and specific return fields (name, email, company, status, channel history), but omits safety characteristics (read-only nature), rate limits, or search matching behavior (exact vs. 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?

  Two sentences with zero waste: first establishes the operation, second describes the return payload. Every word earns its place and critical 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?

  For a 4-parameter search tool with simple types and no output schema, the description adequately compensates by documenting the return structure and pagination behavior. Lacking annotations, it could still benefit from safety disclaimers, but covers the essential contract.

  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%, providing full parameter documentation. The description does not add parameter-specific semantics or usage hints beyond the schema, warranting the baseline score of 3.

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

  Purpose4/5

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

  The description clearly states the core action ('Search and filter') and resource ('leads'), establishing specific scope. While it doesn't explicitly differentiate from siblings, the tool name and description together make the distinct purpose clear relative to the 'create', 'get', and 'list' siblings.

  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?

  Provides implicit guidance through the verb 'Search and filter' indicating this is for querying existing records, but lacks explicit when-to-use guidance or mention of alternatives. Given the distinct naming from siblings (create_agent, get_activity, etc.), the agent can infer appropriate usage.

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

• setup_businessA
  3.6/5.0
  Behavior3/5

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

  No annotations provided, so description carries full disclosure burden. It correctly signals write operations ('Creates', 'deploys') and side effects. However, lacks details on atomicity (failure handling if product creates but agents fail), reversibility, credit consumption, or return values.

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

  Conciseness4/5

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

  Three sentences with logical progression from high-level goal to implementation details to parameter enumeration. Minor inefficiency in restating enum values in description that are fully documented in schema, otherwise front-loaded and clear.

  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?

  Adequate for a 3-parameter tool with good schema coverage, but given the complexity of multi-resource creation (product + agents) and absence of output schema or annotations, the description lacks critical behavioral context such as success/error response format or rollback behavior.

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

  Parameters3/5

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

  Schema coverage is 100%, establishing baseline 3. Description redundantly lists enum values ('Available types: coach...') already present in schema, but adds no additional syntax guidance, validation rules, or semantic relationships between parameters (e.g., how website influences personalization).

  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?

  Specific verbs 'Set up', 'Creates', and 'deploys' clearly identify the scope (complete outreach autopilot, product, AI agents). Explicitly distinguishes from siblings create_agent and create_product by indicating this is a composite operation that orchestrates multiple resources based on business type.

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

  Usage Guidelines3/5

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

  The term 'Set up' implies initial business onboarding use case, but provides no explicit when-to-use guidance versus individual create_agent/create_product calls, prerequisites (e.g., existing business validation), or warnings about idempotency.

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

• get_funnelA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Explains what data returns (conversion at each stage) which is valuable behavioral context. However, omits read-only safety confirmation, error conditions (e.g., invalid agentId), or rate limiting 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?

  Single efficient sentence with critical parenthetical stage enumeration. Front-loaded with core action ('Get the prospect funnel'). No redundant words or repetition of schema elements. Every clause earns its place by conveying funnel-specific information.

  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?

  Adequate for a 2-parameter read operation without output schema. Describes return value conceptually (conversion stages). Could improve by mentioning error handling (e.g., agent not found) or data freshness, but satisfies requirements for this complexity 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?

  Schema coverage is 100% with complete descriptions for agentId and platform. Description mentions 'for an agent' which loosely maps to agentId parameter, but adds no syntax details, format examples, or semantic constraints beyond what schema already provides. Baseline score appropriate for high-coverage schemas.

  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 uses specific verb 'Get' with specific resource 'prospect funnel' and distinguishes from siblings by detailing unique conversion stages (discovered → contacted → engaged → replied → converted). Clearly differentiates from generic 'get_agent_stats' or 'get_dashboard' siblings.

  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?

  Implies usage context (analyzing conversion pipeline for a specific agent) but lacks explicit guidance on when to choose this over 'get_agent_stats' or 'get_activity'. No explicit alternatives or exclusions mentioned.

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

• resume_agentA
  3.9/5.0
  Behavior3/5

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

  Annotations are absent, so description carries full burden. It adds valuable behavioral context that 'scheduled actions' will resume, but omits idempotency, error states (what happens if agent isn't paused), and side effects.

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

  Conciseness5/5

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

  Two efficient sentences with zero waste. Front-loaded with the action (resume), followed by behavioral consequence. Appropriate length for single-parameter tool.

  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?

  Adequate for low-complexity tool (1 param, no output schema, flat structure) with 100% schema coverage. However, given zero annotations and state-changing nature, gaps exist regarding error handling and state validation.

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

  Parameters4/5

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

  Schema coverage is 100%, establishing baseline 3. Description adds semantic value by implying the agentId must refer to a 'paused' agent, providing necessary context beyond the schema's plain ID description.

  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?

  Specific verb 'Resume' + resource 'agent' clearly stated. The phrase 'scheduled actions again' effectively distinguishes this from sibling 'run_agent' (immediate execution) and implies the inverse relationship to 'pause_agent'.

  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?

  Implies prerequisite state ('paused agent') but lacks explicit when-to-use guidance or warnings against using on already-active agents. No explicit alternatives mentioned despite relevant siblings existing.

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

• list_templatesA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It discloses what data is returned ('business types with their default channels'), but omits safety traits (read-only?), pagination behavior, or cache characteristics typical for list operations.

  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?

  Two efficient sentences with zero waste. First establishes purpose and sibling relationship; second describes return payload. Perfectly 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?

  Appropriate for a simple zero-parameter tool. Description compensates for missing output schema by describing what is shown (business types, channels, descriptions), though it could note any pagination limits.

  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?

  Zero parameters present, which per guidelines establishes a baseline of 4. The description appropriately requires no additional parameter context.

  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?

  Excellent clarity with specific verb 'List', resource 'business templates', and explicit relationship to sibling tool 'setup_business' that distinguishes its purpose from generic list operations like list_agents.

  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?

  Provides implied context that these templates are for setup_business, but lacks explicit guidance on when to call this (before vs during setup), prerequisites, or when to avoid using templates.

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