Server Quality Checklist

Tool Scores

• get-metricsC
  2/5.0
  Behavior1/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 but fails completely. 'Get metrics data' reveals nothing about whether this is a read-only operation, whether it requires authentication, what rate limits might apply, what format the data returns in, or any other behavioral characteristics. For a data retrieval tool with zero annotation coverage, this is a critical gap that leaves the agent with no understanding of how the tool behaves.

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

  Conciseness5/5

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

  The description is extremely concise at just three words. While this represents severe under-specification in terms of content, from a pure conciseness perspective it contains zero wasted words and is front-loaded with the core action. Every word earns its place, even though that place is inadequate for proper tool understanding.

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

  Completeness1/5

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

  Given a 5-parameter tool with no annotations and no output schema, the description 'Get metrics data' is completely inadequate. It provides no information about what metrics are available, what system they come from, what the return format looks like, or any behavioral characteristics. For a data retrieval tool of this complexity, the description fails to provide the minimal contextual information needed 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?

  The schema description coverage is 100%, meaning all 5 parameters are well-documented in the input schema itself. The description adds absolutely no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description, which applies here.

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

  Purpose2/5

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

  The description 'Get metrics data' is a tautology that essentially restates the tool name 'get-metrics'. It provides no specific information about what kind of metrics, from what system, or what scope. While it includes a verb ('Get') and resource ('metrics data'), it lacks any distinguishing details that would help differentiate it from potential sibling tools or clarify its specific function beyond the obvious.

  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?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, appropriate contexts, or comparisons to sibling tools like 'get-trace-stats' or 'get-trace-by-id' that might handle similar data. The agent receives no help in determining when this specific metrics retrieval tool is appropriate versus other data-fetching tools in the server.

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

• delete-projectC
  2.1/5.0
  Behavior1/5

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

  With no annotations provided, the description carries full burden but discloses nothing beyond the basic action. It fails to address critical behavioral traits: whether deletion is permanent or reversible, required permissions, side effects (e.g., on associated data), error conditions, or response format. For a destructive operation, this lack of transparency is severe.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence, 'Delete a project', which is front-loaded and wastes no words. While under-specified, it efficiently communicates the core action without redundancy or fluff.

  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 (destructive operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It does not compensate for missing behavioral context, usage guidelines, or output expectations, leaving significant gaps for an AI agent to understand and invoke the tool safely.

  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 clear parameter documentation in the schema itself. The description adds no parameter semantics beyond what the schema provides, such as explaining 'projectId' format or 'workspaceName' usage. However, the baseline score of 3 is appropriate since the schema adequately covers parameters.

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

  Purpose2/5

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

  The description 'Delete a project' is a tautology that restates the tool name without adding meaningful context. It specifies the verb 'Delete' and resource 'project', but lacks distinction from sibling tools like 'delete-prompt' or details about what deletion entails. This minimal statement fails to clarify scope or differentiate from alternatives.

  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. It does not mention prerequisites (e.g., project existence), exclusions (e.g., irreversible effects), or comparisons to sibling tools like 'update-project' or 'list-projects'. The description offers no context for decision-making.

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

• update-promptC
  2.1/5.0
  Behavior1/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 but offers none. It doesn't indicate whether this is a read-only or destructive operation, what permissions are required, whether changes are reversible, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this complete lack of behavioral information is inadequate and potentially misleading.

  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 maximally concise at just three words, with zero wasted language. Every word earns its place by identifying the core action and resource. While this conciseness comes at the expense of completeness, the structure is front-loaded and efficient from a pure brevity perspective.

  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 that this is a mutation tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what 'updating' entails beyond the name parameter, what happens to other prompt attributes, what the tool returns, or any error conditions. For a tool that modifies data, this minimal description leaves critical gaps in understanding its behavior and outcomes.

  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 both parameters ('promptId' and 'name') clearly documented in the schema. The description adds no additional parameter information beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description, which applies here.

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

  Purpose2/5

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

  The description 'Update a prompt' is a tautology that restates the tool name without adding meaningful context. While it correctly identifies the verb ('update') and resource ('prompt'), it fails to specify what aspects of a prompt can be updated or distinguish this tool from sibling tools like 'update-project'. This minimal statement provides no differentiation or specificity beyond the name itself.

  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?

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing prompt ID), exclusions, or relationships to sibling tools like 'create-prompt', 'delete-prompt', or 'get-prompt-by-id'. Without any context about appropriate usage scenarios, the agent has no basis for making informed decisions about tool selection.

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

• create-promptC
  2.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. 'Create a new prompt' implies a write/mutation operation but provides no details about permissions needed, whether creation is idempotent, what happens on conflicts, or what the response contains. This leaves significant behavioral gaps for a creation tool.

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

  Conciseness5/5

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

  The description is extremely concise at just three words. While it's under-specified in content, it's not verbose or poorly structured. Every word earns its place in this minimal description.

  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 inadequate. It doesn't explain what a 'prompt' is in this context, what fields beyond 'name' might be set by default, what the creation response looks like, or how this differs from similar tools. The description fails to provide necessary context 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 the single 'name' parameter. The description adds no additional parameter context beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.

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

  Purpose2/5

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

  The description 'Create a new prompt' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this tool from sibling tools like 'create-prompt-version' or explain what kind of prompt is being created. The purpose is minimally stated but lacks meaningful differentiation.

  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 about when to use this tool versus alternatives like 'create-prompt-version' or 'update-prompt'. There's no mention of prerequisites, constraints, or appropriate contexts for invoking this creation tool versus other prompt-related operations.

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

• get-trace-statsC
  2.7/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 it 'gets' statistics without disclosing behavioral traits like read-only nature, potential rate limits, authentication needs, or what happens if parameters are omitted. It fails to compensate for the lack of annotations.

  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's appropriately sized and front-loaded, making it easy to parse quickly without 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?

  Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what statistics are returned, how they're formatted, or error conditions, leaving significant gaps for the agent to infer 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 description coverage is 100%, so parameters are fully documented in the schema. The description adds no meaning beyond the schema, such as explaining how parameters interact or default behaviors. 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.

  Purpose3/5

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

  The description 'Get statistics for traces' states a clear verb ('Get') and resource ('statistics for traces'), but it's vague about what specific statistics are retrieved and doesn't distinguish from sibling tools like 'get-metrics' or 'get-trace-by-id'. It provides basic purpose but lacks specificity.

  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 'get-metrics' or 'list-traces'. The description doesn't mention prerequisites, exclusions, or context for usage, leaving the agent without direction on tool selection.

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

• list-tracesC
  2.7/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 the action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, pagination behavior, rate limits, authentication needs, or what the output looks like (e.g., list format, error handling). This leaves significant gaps for a tool with 5 parameters.

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

  Conciseness5/5

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

  The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly without unnecessary detail.

  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 (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values, pagination implications, or how filtering parameters interact, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.

  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 parameters like 'page', 'size', 'projectId' are well-documented in the schema. The description adds no additional meaning beyond 'list of traces', such as explaining how filtering works or parameter interactions, meeting the baseline for high schema coverage.

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

  Purpose3/5

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

  The description 'Get a list of traces' states the basic action (get/list) and resource (traces), making the purpose understandable. However, it's vague about what 'traces' are (e.g., execution traces, logging traces) and doesn't distinguish from siblings like 'get-trace-by-id' or 'get-trace-stats', missing specificity for a 4-5 score.

  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 'get-trace-by-id' for single traces or 'get-trace-stats' for aggregated data. The description lacks context about filtering capabilities or typical use cases, offering minimal help for selection.

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

• update-projectC
  2.7/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 full burden. 'Update a project' implies a mutation operation but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. It lacks critical context for a write operation.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence, 'Update a project', which is front-loaded and wastes no words. It efficiently communicates the core action, though this brevity contributes to gaps in other dimensions.

  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 as a mutation with 4 parameters and no annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or return values, leaving significant gaps for an AI agent to understand and invoke it correctly.

  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 (projectId, name, description, workspaceName). The description adds no meaning beyond what the schema provides, such as explaining interdependencies or default behaviors. 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.

  Purpose3/5

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

  The description 'Update a project' states the verb and resource but is vague about what aspects can be updated. It distinguishes from siblings like 'create-project' and 'delete-project' by specifying 'update', but doesn't clarify scope compared to 'update-prompt' or differentiate from partial updates vs full replacements.

  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 doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to siblings like 'get-project-by-id' for read operations or 'list-projects' for discovery.

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

• create-projectC
  2.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 of behavioral disclosure. It states the action ('Create') but doesn't cover critical aspects like required permissions, whether the creation is idempotent, what happens on conflicts, or the expected response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words—it directly states the tool's purpose without unnecessary elaboration. It's appropriately sized and front-loaded, 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?

  Given that this is a mutation tool ('Create') with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'project' or 'workspace' entails in this system, how to handle errors, or what the tool returns upon success, leaving the agent with incomplete context 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?

  The description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage with clear descriptions for all three parameters. This meets the baseline of 3, as the schema adequately documents the parameters, but the description doesn't provide additional context like examples or usage notes.

  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 'Create a new project/workspace' clearly states the verb ('Create') and resource ('project/workspace'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'create-prompt' or explain what differentiates a 'project' from a 'workspace' in this context, which prevents a perfect score.

  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-project' or 'list-projects', nor does it mention prerequisites or constraints. While the verb 'Create' implies it's for new entities, there's no explicit comparison to siblings or context for usage decisions.

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

• create-prompt-versionC
  2.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 of behavioral disclosure. It states the tool creates a new version but doesn't explain what that entails—whether it's a write operation, requires specific permissions, affects existing prompts, or has side effects like triggering notifications. For a mutation tool with zero annotation coverage, this lack of detail is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Create a new version'), making it easy to parse quickly. Every word earns its place, and there's no redundancy or fluff.

  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 complexity of a versioning operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, idempotency, or error handling, nor does it hint at return values. For a tool that modifies data, this leaves critical gaps for an AI agent to understand its full 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 fully documents the three parameters (name, template, commit_message). The description adds no additional meaning beyond what's in the schema, such as explaining how 'name' relates to the original prompt or what 'commit_message' is used for. With high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to.

  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 version of a prompt'), making the purpose immediately understandable. It distinguishes from siblings like 'create-prompt' (which creates a new prompt rather than a version) and 'update-prompt' (which might modify an existing prompt without versioning). However, it doesn't specify what constitutes a 'version' (e.g., whether it's a snapshot, revision, or branch), leaving some ambiguity.

  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 (e.g., needing an existing prompt), compare to siblings like 'update-prompt' or 'create-prompt', or indicate scenarios where versioning is appropriate (e.g., for tracking changes, experimentation, or deployment). Without this, users 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.

• delete-promptC
  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 states the action is destructive ('Delete') but doesn't elaborate on consequences (e.g., permanent deletion, no undo), permissions required, or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is extremely concise at three words, front-loading the essential action and resource without any wasted text. Every word earns its place, 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?

  Given the tool's destructive nature, no annotations, and no output schema, the description is incomplete. It lacks critical information about behavioral traits (e.g., irreversibility), error handling, or what happens post-deletion. For a deletion tool, this leaves significant gaps in 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?

  The description adds no parameter semantics beyond what the schema provides. Since schema description coverage is 100% (the 'promptId' parameter is fully documented in the schema), the baseline score is 3. The description doesn't compensate with additional context like format 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 ('Delete') and the resource ('a prompt'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like 'delete-project' by specifying the resource type, though it doesn't explicitly contrast with other deletion tools. The description avoids tautology by not merely restating the 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a prompt ID), exclusions (e.g., cannot delete if in use), or sibling tools like 'delete-project' for different resources. Usage is implied by the action but lacks explicit context.

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

• get-opik-examplesC
  2.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 of behavioral disclosure. It states the tool retrieves examples but doesn't describe what the output looks like (e.g., format, structure), whether it's a read-only operation, or any limitations like rate limits or authentication needs. This leaves significant gaps for an AI agent to understand how to handle the tool's behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, which is ideal for conciseness.

  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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., code snippets, documentation), how examples are structured, or any behavioral traits. For a tool with no structured data beyond the input schema, the description should provide more context to help an AI agent 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?

  The input schema has 100% description coverage, with the 'task' parameter clearly documented. The description doesn't add any additional meaning beyond what the schema provides, such as explaining the semantics of example tasks or providing usage context. With high schema coverage, the baseline score of 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 tool's purpose with a specific verb ('Get') and resource ('examples of how to use Opik Comet's API'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get-opik-help' or 'get-opik-tracing-info', which might provide related but different information.

  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 it's appropriate (e.g., for learning API usage) or when not to use it (e.g., for direct API calls), nor does it reference sibling tools like 'get-opik-help' that might serve similar purposes.

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

• get-opik-tracing-infoC
  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 disclosing behavioral traits. It doesn't cover aspects like whether it's a read-only operation, potential rate limits, authentication needs, or output format, which are critical for an agent to use it effectively.

  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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, though it could be slightly more structured by including brief usage hints.

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

  Completeness3/5

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

  Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It explains what the tool does but doesn't provide enough context about behavior or usage relative to siblings, making it adequate but with clear gaps for an 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?

  The input schema has 100% description coverage, clearly documenting the optional 'topic' parameter with examples. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced 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 verb 'Get' and the resource 'information about Opik's tracing capabilities and how to use them', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-trace-by-id' or 'get-trace-stats', which also deal with tracing information but focus on specific data rather than general capabilities.

  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 scenarios like needing overviews versus detailed data, or how it differs from siblings such as 'get-opik-help' or 'get-opik-examples', leaving the agent to infer usage from context alone.

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

• get-project-by-idC
  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. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, what happens if the project doesn't exist, or any rate limits. The description lacks crucial behavioral context that would help an agent understand how to handle errors or what to expect from the operation.

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

  Conciseness5/5

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

  The description is extremely concise at just 6 words, front-loading the essential information with zero wasted words. Every word earns its place by communicating the core functionality without 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 read operation with 2 parameters and no output schema, the description is insufficiently complete. It doesn't explain what information the tool returns about projects, how to handle the optional workspaceName parameter, or what format the response takes. With no annotations and no output schema, the agent lacks crucial information about the tool's behavior and outputs.

  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 fully documents both parameters (projectId and workspaceName). The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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 ('Get') and resource ('a single project by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'list-projects' by specifying retrieval of a single item rather than a collection. However, it doesn't explicitly differentiate from 'get-prompt-by-id' or 'get-trace-by-id' which follow similar 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 when to prefer this over 'list-projects' for single-item retrieval, or how it relates to other 'get-by-id' tools for different resource types. There's also no information about prerequisites or contextual constraints.

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

• get-prompt-by-idC
  2.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 full burden but only states the basic action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, what happens with invalid IDs (e.g., errors), authentication needs, rate limits, or return format, leaving significant gaps in transparency.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence that directly states the tool's purpose, making it front-loaded and free of unnecessary words. Every part of the sentence earns its place by clearly conveying the core functionality.

  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 complexity of a retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what data is returned (e.g., prompt content, metadata), error handling, or how it fits into the broader context of prompt management, failing to compensate for the lack of structured data.

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

  Parameters3/5

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

  The description adds no meaning beyond the input schema, which has 100% coverage and fully documents the 'promptId' parameter. With high schema coverage, the baseline is 3, as the schema handles parameter documentation adequately without extra detail from 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 verb 'Get' and the resource 'a single prompt by ID', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-project-by-id' or 'list-prompts', which would require mentioning it retrieves individual prompt details rather than projects or lists.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as 'list-prompts' for browsing or 'get-project-by-id' for related resources. It lacks context about prerequisites like needing a valid prompt ID or exclusions for non-existent IDs, leaving usage unclear.

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

• get-trace-by-idC
  2.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 of behavioral disclosure. It states it's a read operation ('get'), but doesn't cover aspects like error handling (e.g., what happens if the trace ID doesn't exist), rate limits, authentication requirements, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Get a single trace by ID'), making it immediately understandable. Every part of the sentence contributes directly to clarifying the tool's function.

  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 no annotations and no output schema, the description is incomplete for a tool with 2 parameters. It lacks details on behavioral traits (e.g., error cases, permissions), return values, and usage context. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially for a read operation that might involve workspace-specific data.

  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 clear descriptions for both parameters: 'traceId' as the ID to fetch and 'workspaceName' as an optional override. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

  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 'Get a single trace by ID' clearly states the action (get) and resource (trace), with specificity about retrieving by ID. It distinguishes from siblings like 'list-traces' (multiple) and 'get-trace-stats' (statistics), though it doesn't explicitly name them. The purpose is unambiguous but lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'list-traces' for multiple traces or 'get-trace-stats' for aggregated data, nor does it specify prerequisites like authentication or workspace context. Usage is implied by the name but not explicitly stated.

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

• list-projectsC
  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 it 'gets a list' which implies a read operation, but doesn't mention pagination behavior (implied by parameters), rate limits, authentication requirements, or what the return format looks like. For a tool with 5 parameters and no output schema, this leaves significant behavioral aspects undocumented.

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

  Conciseness5/5

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

  The description is extremely concise at just 5 words, front-loading the core purpose with zero wasted words. Every element ('Get', 'list', 'projects/workspaces') earns its place. No structural issues or 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 tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a 'project' or 'workspace' represents in this context, doesn't describe the return format, and provides no behavioral context. The agent would need to infer too much from just the schema parameters.

  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 all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. It doesn't explain relationships between parameters (e.g., how 'workspaceName' interacts with the list) or provide usage examples. 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 a list') and resource ('projects/workspaces'), making the purpose immediately understandable. However, it doesn't distinguish between 'projects' and 'workspaces' or clarify if they're synonymous, and it doesn't differentiate from sibling tools like 'get-project-by-id' or 'list-prompts' which serve different but related purposes.

  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 to choose 'list-projects' over 'get-project-by-id' for retrieving specific projects, or 'list-prompts' for different resource types. There are no prerequisites, exclusions, or context for usage decisions.

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

• list-promptsC
  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 the tool retrieves a list but doesn't mention pagination behavior (implied by parameters), rate limits, authentication needs, or what the return format looks like (no output schema). This leaves significant gaps for an agent to understand how the tool behaves.

  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 wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  For a list tool with 2 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain pagination requirements, return format, or error conditions. Given the complexity (simple but with required params) and lack of structured data, more context is needed for the agent to use this tool 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 ('page' and 'size') clearly documented in the schema. The description adds no additional parameter semantics beyond implying list retrieval, so it meets the baseline score of 3 where 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 'Get a list of Opik prompts' clearly states the verb ('Get') and resource ('Opik prompts'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'list-projects' or 'list-traces' beyond the resource type, nor does it specify scope (e.g., all prompts vs. filtered).

  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-prompt-by-id' for retrieving a specific prompt, or 'create-prompt' for adding new prompts. There's no mention of prerequisites, typical use cases, or limitations that would help an agent choose appropriately.

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

• get-opik-helpB
  3.1/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 of behavioral disclosure. It states the tool retrieves help information, implying a read-only operation, but doesn't mention any behavioral traits like rate limits, authentication needs, or what the output format might be. This is a significant gap for a tool with no annotation coverage.

  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 any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

  Completeness3/5

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

  Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It explains what the tool does but lacks details on behavioral aspects and usage context, which are important for an agent to operate effectively without annotations.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both parameters ('topic' and 'subtopic') with their types and purposes. The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 where 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 verb 'Get' and the resource 'contextual help about Opik Comet's capabilities', making the purpose understandable. However, it doesn't specifically differentiate from sibling tools like 'get-opik-examples' or 'get-opik-tracing-info', which also provide information about Opik Comet but focus on different aspects.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as 'get-opik-examples' or 'get-opik-tracing-info'. It lacks explicit context, exclusions, or prerequisites, leaving the agent to infer usage based on 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-server-infoB
  3.1/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 states it 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, response format, or potential side effects. This leaves significant gaps for a tool with no annotation coverage.

  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 appropriately sized and front-loaded, 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?

  Given no annotations and no output schema, the description is incomplete. It lacks details on what specific server configuration information is returned, how it's structured, or any behavioral context. For a tool in a set with many siblings, more completeness is needed to guide effective use.

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

  Parameters4/5

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

  The input schema has 1 parameter with 100% coverage, describing it as a 'Dummy parameter for no-parameter tools'. The description adds no parameter information, which is acceptable since the schema fully documents the parameter, and the tool effectively has 0 functional parameters. Baseline is 3, but the dummy nature justifies a higher score for clarity.

  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 'information about the Opik server configuration', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'get-metrics' or 'get-opik-tracing-info', which also retrieve server-related information, so it misses full sibling 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. With siblings like 'get-metrics' and 'get-opik-tracing-info' that might retrieve overlapping or related server data, there's no indication of context, prerequisites, or exclusions for tool selection.

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