Server Quality Checklist

Tool Scores

• get_agent_requirementsD
  1.5/5.0
  Behavior2/5

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

  The description mentions that using the same conversation_id appends requirements, which is a behavioral trait. However, it does not disclose side effects, authentication needs, or what happens to existing data. With no annotations, the description carries full responsibility for behavioral disclosure, which it largely fails to meet.

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

  Conciseness1/5

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

  The description is excessively long (over 1000 words) and poorly structured, with sections like 'Prompt' and 'Conversation Guide' that are irrelevant for a tool definition. It front-loads a system prompt instead of a concise tool description, wasting the agent's attention.

  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 simple 2-parameter schema and no output schema, the description should clearly state what the tool does and returns. It fails to do so, omitting the return value, error handling, and core purpose. The description is not complete enough for an agent to reliably invoke the tool.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It adds some context: conversation_id ties to a conversation and requirements are appended. But it does not explain the format or constraints of the requirements array, nor clarify what the tool returns. The meaning is partially conveyed but incomplete.

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

  Purpose1/5

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

  The description is a verbose system prompt for conducting a discovery conversation, not a clear statement of what the tool does. It fails to specify that the tool stores or retrieves agent requirements, and instead instructs the AI on how to have a conversation. This is severely misleading and does not communicate the tool's function.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives. Sibling tools (deploy_agent_tool, generate_agent_metadata) are listed, but the description does not differentiate this tool's role or provide context for choosing it.

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

• generate_agent_metadataB
  3.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It discloses that the tool will ask for company name and agent name, generate utterances, and produce JSON. It also lists extensive rules and steps. However, it doesn't mention side effects, authentication needs, or data handling beyond the task. Still, it provides substantial behavioral context.

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

  Conciseness2/5

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

  The description is excessively long (many paragraphs) with detailed instructions that could be shortened. It has some front-loading with the job statement, but then includes many rules, formatting notes, and examples that make it verbose. Many sentences could be removed without losing meaning.

  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 no output schema, the description should fully explain return values. It mentions the tool returns 'generated agent metadata' but does not specify the exact JSON format or fields. The complexity is moderate with one nested parameter. The description provides many procedural details but lacks some completeness on inputs/outputs.

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

  Parameters2/5

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

  Schema coverage is 0% – the description does not explain the 'agent_metadata' parameter meaningfully beyond a brief line at the end: 'Args: agent_metadata: The agent metadata as a dictionary'. With a nested object and additionalProperties: true, more context is needed. The description's bulk focuses on how to process the parameter, not what it is.

  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 job: 'create a description of an AI Agent, generating sample utterances, and convert a list of topics into a specific JSON format.' This distinguishes it from sibling tools deploy_agent_tool and get_agent_requirements. However, the description is overloaded with instructions that could be seen as part of the tool's use rather than its core purpose.

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

  Usage Guidelines3/5

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

  The description implies the tool is used to generate agent metadata given agent_metadata input, but it doesn't explicitly state when to use it vs alternatives. No 'when-not' or exclusions are provided. The sibling tools have different purposes, but the description lacks direct usage guidance.

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

• deploy_agent_toolA
  4.1/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses deployment behavior, error handling steps, and return value including login URL. Could mention potential side effects like modifying org.

  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?

  Well-structured with bullet-point rules and explicit Args/Returns sections. Concisely communicates key information, though the two identical 'Deployment failed' returns are slightly redundant.

  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?

  Adequately covers prerequisite, user interaction, failure scenarios, and return format. Lacks details on agent_metadata structure, but overall sufficient for a deployment tool without output schema.

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

  Parameters3/5

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

  Only one parameter (agent_metadata) with no schema description (0% coverage). Description adds basic meaning as 'agent metadata to deploy as a dictionary' but lacks structure details or examples typical for a nested object.

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

  Purpose5/5

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

  Description clearly states 'Deploy a previously generated agent to Salesforce.' It uses a specific verb (deploy) and resource (agent), and distinguishes from sibling tools: generate_agent_metadata creates metadata, get_agent_requirements retrieves requirements.

  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?

  Describes when to use (after generate_agent_metadata) and instructs to always ask user first. Provides handling for failure cases. Lacks explicit when not to use but covers key usage context.

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