Server Quality Checklist

Tool Scores

• run_lsdC
  2.4/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. It mentions 'using user credentials in .env', hinting at authentication needs, but doesn't disclose behavioral traits such as whether it's read-only or destructive, rate limits, or what the tool actually does beyond running SQL. This leaves significant gaps for a tool that likely executes SQL queries.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, though it could benefit from more detail given the lack of annotations and schema coverage.

  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 running SQL queries, no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what LSD SQL is, what the tool returns, or any error handling, making it inadequate for safe and effective use.

  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 doesn't add any meaning to the parameter 'lsd_sql_code' beyond what's implied by the name. No details on syntax, format, or examples are provided, failing to address the coverage gap.

  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 states the tool 'Runs LSD SQL using user credentials in .env', which provides a verb ('Runs') and resource ('LSD SQL'), but it's vague about what LSD SQL is and doesn't distinguish it from sibling tools like 'view_lsd'. It's not tautological 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 'search_trips' or 'view_lsd'. The description mentions user credentials in .env, which implies a context for authentication, but doesn't specify use cases or exclusions.

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

• search_tripsC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions returning a list but doesn't specify whether this is a read-only operation, if it requires authentication, what happens on errors, or any rate limits. This leaves significant gaps for a tool that presumably interacts with user data.

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

  Conciseness3/5

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

  The description is a single sentence that is reasonably concise, but it's not front-loaded with critical information and includes vague phrasing like 'what each of them do' which adds little value. It could be more structured to clarify purpose upfront.

  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 searching user-available trips, no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what the returned objects contain, how results are filtered, or any behavioral traits, making it inadequate for effective tool use.

  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?

  The input schema has one parameter 'query' with 0% description coverage, and the tool description provides no information about what the 'query' parameter should contain, its format, or examples. This fails to compensate for the low schema coverage, leaving the parameter undocumented.

  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 states the tool 'returns a list of objects with LSD trips available to the user', which provides a basic purpose (verb+resource). However, it's vague about what 'objects' contain and what 'what each of them do' means, and it doesn't distinguish this tool from siblings like 'view_lsd' or 'use_trip'.

  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 'view_lsd' or 'use_trip'. The description implies it's for searching available trips, but there's no explicit context, exclusions, or prerequisites mentioned.

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

• use_tripC
  2.4/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 mentions 'invokes a trip on LSD,' which suggests a mutation or action, but fails to describe key traits such as permissions required, side effects, error handling, or response format. The phrase '[ACCORDING TO] keywords' adds some context but is vague and insufficient for understanding 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.

  Conciseness3/5

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

  The description is brief with one sentence, which is appropriately sized for a simple tool. However, the phrase '[ACCORDING TO] keywords' is unclear and adds noise without value, reducing efficiency. It is front-loaded with the main action but could be more streamlined by omitting ambiguous elements.

  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 (involving 'invoking' a trip on LSD), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It does not cover essential aspects like what the tool returns, error conditions, or prerequisites, making it inadequate for effective use by an AI agent without additional context.

  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?

  The input schema has 1 parameter with 0% description coverage, and the description does not add meaningful semantics beyond the schema. It references 'trip_identifier' indirectly but does not explain what this identifier is, its format, or how to obtain it. With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.

  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 states the tool 'invokes a trip on LSD based on its identifier,' which provides a vague purpose with the verb 'invokes' and resource 'trip on LSD.' However, it lacks specificity about what 'invokes' means (e.g., starts, executes, triggers) and does not clearly differentiate from sibling tools like 'run_lsd' or 'search_trips,' leaving ambiguity in its exact function.

  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 includes the phrase 'using the [ACCORDING TO] keywords,' which implies some context or method for usage, but it does not provide explicit guidance on when to use this tool versus alternatives like 'run_lsd' or 'search_trips.' There are no clear when/when-not instructions or named alternatives, resulting in minimal actionable guidance.

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

• view_lsdC
  2.8/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 tool returns a URL but doesn't describe what the URL leads to in detail, whether it's interactive or static, if authentication is needed, or any side effects. 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, well-structured sentence that efficiently conveys the core functionality without unnecessary details. It's front-loaded and wastes no words, making it highly concise.

  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 (1 parameter, no annotations, no output schema), the description is incomplete. It lacks details on the URL's nature, expected input format, and how it differs from siblings like 'run_lsd', making it inadequate for full agent understanding.

  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?

  The description mentions 'LSD SQL evaluation' but doesn't explain the 'lsd_sql_code' parameter beyond what's implied. With 0% schema description coverage and 1 required parameter, the description fails to add meaningful semantics, such as the format or purpose of the code input.

  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: 'Returns a URL to a page where the user can view results as well as a visual playback of LSD SQL evaluation.' It specifies the verb ('Returns a URL') and resource ('page for viewing LSD SQL evaluation results and playback'), though it doesn't explicitly differentiate from sibling tools like 'run_lsd' or 'search_trips'.

  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 'view_lsd' over 'run_lsd' or other siblings, nor does it specify prerequisites or exclusions, leaving usage context unclear.

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