Server Quality Checklist

Tool Scores

• calendar-list-eventsC
  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 for behavioral disclosure. It mentions 'optional filters' which hints at query capabilities, but doesn't describe pagination behavior, rate limits, authentication requirements, error conditions, or what happens with large result sets. For a list operation with 6 parameters, 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 - a single 7-word sentence that efficiently communicates the core functionality. It's front-loaded with the essential information and contains no wasted words or redundant information.

  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 operation with 6 parameters and no output schema, the description is insufficient. It doesn't explain what information events contain, how results are structured, whether there's pagination, or what happens when filters return no results. Without annotations and with no output schema, the description should provide more context about the operation's behavior and results.

  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 mentions 'optional filters' which aligns with the schema's filtering parameters (timeMin, timeMax, maxResults, etc.). However, with 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal value beyond what's in the schema - it doesn't explain filter interactions, precedence, or practical usage patterns.

  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 'List calendar events with optional filters' clearly states the verb ('List') and resource ('calendar events'), but it's somewhat vague about scope and doesn't differentiate from sibling tools like 'calendar-get-event' or 'calendar-list-calendars'. It specifies the action but lacks precision about what kind of listing this provides.

  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. There are multiple calendar-related siblings (create-event, delete-event, get-event, list-calendars), but the description doesn't indicate this is for listing multiple events with filtering capabilities versus getting a single event or listing calendars.

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

• calendar-create-eventC
  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 full burden for behavioral disclosure. It states the tool creates events but doesn't mention what permissions are required, whether events are immediately published, how conflicts are handled, or what the response looks like. The timestamp inclusion is irrelevant behavioral information.

  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 core purpose statement is concise, but the timestamp 'Current time: 1/3/2026, 9:03:13 AM' adds unnecessary clutter that doesn't help an AI agent understand the tool. This wasted space reduces the score despite the otherwise efficient phrasing.

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

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation, error conditions, authentication requirements, or response format. The timestamp inclusion doesn't address these critical gaps.

  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 all 8 parameters. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline expectation when schema coverage is complete.

  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 calendar event'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'calendar-update-event' beyond the obvious create vs. update distinction, and the timestamp inclusion is irrelevant to purpose.

  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 'calendar-update-event' or 'calendar-list-events'. There's no mention of prerequisites, permissions needed, or contextual factors that would influence tool selection.

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

• airports-searchC
  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 but only states the basic function. It doesn't mention rate limits, authentication needs, data freshness, error conditions, or what kind of results to expect (e.g., flight prices, schedules). For a complex search tool with 12 parameters, this is inadequate.

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

  Conciseness5/5

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

  The description is a single, clear sentence that efficiently communicates the core purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to quickly understand 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 the tool's complexity (12 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what the output looks like (flight data format), behavioral constraints, or error handling. For a flight search tool that likely returns structured data, more context is needed to help the 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, so all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema, maintaining the baseline score of 3 since 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 searches for airport and flight information using Google Flights, specifying both the resource (airport/flight info) and the data source (Google Flights). However, it doesn't differentiate from sibling tools like 'places-search' or 'distance-matrix' that might also handle location-based queries, so it misses full 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 sibling tools or other contexts where flight search might be preferred over general place searches or distance calculations, leaving the agent with no explicit usage instructions.

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

• calendar-delete-eventC
  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 the action without behavioral details. It doesn't disclose whether deletion is permanent, requires specific permissions, has confirmation prompts, or affects related calendar data, leaving critical mutation behavior opaque.

  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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.

  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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavior, error conditions, return values, or safety considerations, leaving significant gaps for agent decision-making.

  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 documented in the schema. The description adds no additional meaning about 'eventId' or 'calendarId' beyond what's in the schema, meeting the baseline for high coverage but not enhancing understanding.

  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 ('Delete') and resource ('a calendar event'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'calendar-update-event' or 'calendar-get-event' beyond the obvious action difference, missing specific scope distinctions.

  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. There's no mention of prerequisites (e.g., needing an existing event), exclusions, or comparison with siblings like 'calendar-update-event' for modifying instead of deleting.

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

• calendar-get-eventC
  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 action ('Get') but doesn't mention whether this is a read-only operation, what permissions are required, error handling (e.g., for invalid IDs), or response format. This leaves significant gaps for a tool that likely 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.

  Conciseness5/5

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

  The description is a single, direct sentence with zero wasted words. It front-loads the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete for a data retrieval tool. It doesn't explain what the tool returns (e.g., event details, error responses) or behavioral aspects like authentication needs. For a tool with two parameters and no structured output documentation, this leaves the agent under-informed.

  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 both parameters (eventId and calendarId). The description adds no additional meaning beyond implying 'eventId' is required for retrieval, which is already clear from the schema's required field. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('specific calendar event by ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'calendar-list-events' or 'calendar-update-event' beyond the implied specificity of retrieving a single event.

  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 'calendar-list-events' for multiple events or 'calendar-update-event' for modifications. It lacks context about prerequisites (e.g., needing an event ID) or exclusions, offering only basic functional information.

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

• calendar-update-eventC
  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. 'Update an existing calendar event' implies a mutation operation but doesn't disclose important behavioral traits: whether this requires specific permissions, if updates are partial or complete replacements, what happens to attendees when updating, whether changes are reversible, or any rate limits/quotas. For a mutation tool with zero annotation coverage, this is a significant gap.

  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 action ('Update an existing calendar event') and contains no unnecessary elaboration. Every word earns its place in conveying the essential purpose.

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

  Completeness2/5

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

  For a mutation tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address key contextual questions: what permissions are needed, whether updates are partial or complete, what the response looks like, error conditions, or how it interacts with sibling tools. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.

  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 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain which fields are optional vs. required beyond eventId, how partial updates work, or provide examples. Baseline 3 is appropriate when the schema does all the parameter documentation work.

  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 ('update') and resource ('existing calendar event'), making the purpose immediately understandable. It distinguishes from sibling tools like 'calendar-create-event' and 'calendar-delete-event' by specifying it's for updating existing events. However, it doesn't specify what aspects can be updated or the scope of changes.

  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 (like needing an existing event ID), when not to use it, or how it differs from 'calendar-create-event' beyond the obvious update vs. create distinction. The agent must infer usage from the tool name alone.

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

• distance-matrixC
  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 mentions 'calculate' but doesn't specify whether this is a read-only operation, requires API keys, has rate limits, or returns structured data. For a tool with no annotation coverage, this 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 front-loads the core functionality without any wasted words. It's appropriately sized for the tool's complexity, making it easy to parse and understand quickly.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters and computational complexity. It doesn't explain return values, error handling, or behavioral traits like authentication needs, which are crucial for an AI agent to use 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?

  The description adds minimal meaning beyond the input schema, which has 100% coverage and includes descriptions for all parameters. It implies the tool handles arrays of locations but doesn't elaborate on format (e.g., addresses, coordinates) or constraints. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.

  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 specific verbs ('calculate travel distance and time') and resources ('between multiple origins and destinations'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-directions' or 'geocode', which might offer related functionality, so it doesn't reach the highest 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, such as 'get-directions' for point-to-point routes or 'geocode' for location conversion. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.

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

• geocodeC
  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. The description only states the basic function without mentioning any behavioral traits such as rate limits, accuracy considerations, error handling, authentication requirements, or what happens with invalid addresses. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves in practice.

  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, clear sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's front-loaded with the core functionality and doesn't include any redundant information.

  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 for effective tool use. While the purpose is clear, it doesn't address important contextual elements like what the output looks like (coordinates format), error conditions, performance characteristics, or integration considerations. For a tool that performs a non-trivial conversion with potential variability in results, more context would be helpful.

  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% (the single parameter 'address' has a clear description in the schema), so the baseline is 3. The tool description doesn't add any parameter-specific information beyond what's already in the schema. It doesn't provide examples of address formats, discuss parameter constraints, or explain how the parameter affects the conversion process.

  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 'Convert an address to coordinates' clearly states the tool's function with a specific verb ('convert') and resource ('address to coordinates'). It distinguishes itself from sibling tools like 'reverse-geocode' by specifying the direction of conversion. However, it doesn't explicitly differentiate from other location-based tools like 'places-search' or 'get-directions' beyond the basic operation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to sibling tools like 'places-search' (which might return coordinates among other data) or 'reverse-geocode' (which does the opposite conversion). There's no context about prerequisites, limitations, or typical use cases.

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

• get-directionsC
  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. 'Get directions' implies a read-only operation, but it doesn't mention rate limits, authentication requirements, response format, or whether this is a real-time or cached service. For a tool with zero annotation coverage, this is insufficient 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward tool and gets directly to the point.

  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 directions tool with no annotations and no output schema, the description is inadequate. It doesn't explain what kind of directions are returned (step-by-step, summary, ETA), whether multiple routes are provided, or any limitations. The agent would need to guess about the output format and behavioral characteristics.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and resource 'directions between two locations', making the purpose immediately understandable. It doesn't differentiate from siblings like 'distance-matrix' or 'geocode', but it's specific enough to understand what the tool does.

  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 'distance-matrix' or 'geocode'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage context 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.

• gmail-get-emailC
  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 ('Get') but doesn't describe what 'get' returns (e.g., full email content, headers, attachments), error conditions (e.g., invalid ID, permissions), or side effects (e.g., marking as read). For a read operation with zero annotation coverage, this leaves significant gaps in 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.

  Conciseness5/5

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

  The description is a single, direct sentence with zero wasted words. It front-loads the core action ('Get a specific email') and specifies the key identifier ('by message ID'), making it highly efficient. Every part of the sentence contributes essential information without redundancy.

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

  Completeness2/5

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

  Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'get' returns (e.g., email body, metadata), potential errors, or how the message ID should be obtained. For a tool that retrieves data, this lack of output and behavioral context makes it inadequate for reliable agent use.

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

  Parameters3/5

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

  The description doesn't add any parameter-specific information beyond what's in the input schema, which has 100% coverage (the 'messageId' parameter is fully described as 'Gmail message ID'). With high schema coverage, the baseline is 3, as the schema already documents the parameter adequately, and the description doesn't compensate with additional context like format examples or sourcing details.

  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 ('a specific email'), making the purpose immediately understandable. It distinguishes from sibling tools like 'gmail-read-emails' (which lists emails) and 'gmail-send-email' (which sends emails). However, it doesn't specify what 'get' entails (e.g., retrieving full content vs metadata), 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. It doesn't mention prerequisites (e.g., needing a valid message ID), contrast with 'gmail-read-emails' for listing emails, or specify use cases like retrieving a single known email. Without such context, the agent must infer usage from the tool name alone.

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

• gmail-read-emailsC
  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 the basic action. It doesn't disclose behavioral traits like authentication requirements, rate limits, pagination behavior, what fields are returned, error conditions, or whether this is a read-only operation (though implied by 'read/list').

  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?

  Extremely concise single sentence with zero waste. Every word earns its place: 'Read/list' establishes the action, 'emails from Gmail' specifies the resource, and 'with optional search query' highlights key 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?

  For a 3-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned, how results are structured, authentication requirements, or error handling. The agent would need to guess about the output format and behavioral characteristics.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'optional search query' which aligns with the 'query' parameter, but doesn't provide additional context about parameter interactions or usage patterns.

  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 ('read/list') and resource ('emails from Gmail') with the optional search capability. It distinguishes from siblings like 'gmail-get-email' (singular) and 'gmail-send-email' (write operation), but doesn't explicitly contrast with 'gmail-get-labels' or other non-email tools.

  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 like 'gmail-get-email' (for a specific email) or 'gmail-get-labels' (for labels). The description mentions optional search query but doesn't provide context for choosing between search parameters or when to use this tool over others.

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

• gmail-send-emailC
  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 ('Send an email') but lacks critical details: it doesn't mention authentication requirements, potential rate limits, whether the email is sent immediately or queued, or what happens on failure. For a mutation tool with zero annotation coverage, this 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 with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for the tool's complexity.

  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 (a mutation operation with 5 parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't address authentication, error handling, return values, or behavioral constraints, leaving the agent with insufficient context for reliable 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 input schema has 100% description coverage, with each parameter clearly documented (e.g., 'to' as 'Recipient email address'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate coverage without extra value.

  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 'Send an email using Gmail' clearly states the verb ('Send') and resource ('email using Gmail'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'gmail-get-email' or 'gmail-read-emails' beyond the obvious action difference, which keeps it from 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. It doesn't mention prerequisites (e.g., authentication needs), when it's appropriate compared to other email-related tools, or any exclusions. This leaves the agent with minimal 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.

• place-detailsC
  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 offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose rate limits, authentication needs, data freshness, error conditions, or what 'detailed information' entails (e.g., address, hours, reviews). This leaves significant gaps for agent decision-making.

  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 front-loads the core purpose ('Get detailed information') without unnecessary words. Every part 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 moderate complexity (retrieving detailed place data), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, potential costs/limits, or how results differ from sibling tools like 'places-search', leaving the agent under-informed 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?

  Schema description coverage is 100% (the single parameter 'place_id' is documented as 'The Google Place ID'), so the baseline is 3. The description adds no additional parameter context beyond what the schema provides, such as where to obtain place_ids or format examples, but doesn't need to compensate for gaps.

  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 ('detailed information about a specific place'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'places-search' or 'geocode', which also retrieve place-related data but with different approaches.

  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 place_id), contrast with 'places-search' (which likely finds places by query), or specify use cases like retrieving comprehensive details versus basic info.

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

• places-searchC
  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 for behavioral disclosure. 'Search for places' implies a read-only operation, but the description doesn't disclose rate limits, authentication requirements, result format, pagination behavior, or any other behavioral traits. It provides minimal context beyond the basic 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-loaded with the core purpose, and contains zero wasted words. Every element ('Search', 'places', 'using text query') contributes essential information about 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?

  For a search tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a 'place', what fields are returned, how results are ranked, or any limitations. The agent would need to guess about the tool's behavior and output format.

  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 three parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it mentions 'text query' which aligns with the 'query' parameter but provides no additional context about parameter interactions or usage patterns.

  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 as 'Search for places using text query', which specifies the verb ('search'), resource ('places'), and method ('text query'). It distinguishes from some siblings like 'geocode' or 'place-details', but doesn't explicitly differentiate from 'airports-search' which is also a places search tool.

  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. There's no mention of when to use 'places-search' versus 'airports-search', 'geocode', 'place-details', or other location-related tools. The agent must infer usage from the tool name alone.

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

• reverse-geocodeC
  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 but only states the basic function. It doesn't cover important aspects like rate limits, accuracy, data sources, error handling, or output format (e.g., address structure, precision), which are critical for a geocoding service.

  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, clear sentence that directly states the tool's purpose without any wasted words. It's perfectly front-loaded and efficiently communicates 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?

  For a tool with no annotations, no output schema, and moderate complexity (coordinate conversion), the description is insufficient. It lacks details on behavioral traits, output expectations, and usage context relative to siblings, leaving significant gaps for an AI agent to operate 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 description adds no parameter semantics beyond what the schema already provides (100% coverage with clear descriptions for latitude and longitude). It doesn't explain coordinate formats (e.g., decimal degrees), ranges, or special cases, so it meets the baseline but adds no extra value.

  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 ('Convert') and resource ('coordinates to an address'), making it immediately understandable. However, it doesn't explicitly differentiate from the sibling 'geocode' tool, which appears to perform the opposite operation (address to coordinates), 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. It doesn't mention the sibling 'geocode' tool for reverse operations or other location-related tools like 'places-search' or 'place-details', leaving the agent without context for tool selection.

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

• calendar-list-calendarsB
  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 full burden for behavioral disclosure. 'List all available calendars' implies a read-only operation but doesn't specify permissions needed, whether it returns personal/shared calendars, pagination behavior, or format of returned data. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality immediately.

  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 (single optional parameter) and 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, the description should ideally clarify what 'calendars' means in this context (metadata, IDs, names) and any scope limitations. It meets minimum viability but has clear gaps.

  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 single parameter 'maxResults'. The description adds no 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 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 ('List') and resource ('all available calendars'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'calendar-list-events', which could cause confusion about whether this lists calendar metadata vs. calendar entries.

  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 sibling tools like 'calendar-list-events' and 'calendar-create-event', there's no indication whether this is for administrative setup, user selection, or other contexts. The agent must infer usage from the name alone.

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

• gmail-get-labelsB
  3.2/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. 'Get all Gmail labels' implies a read-only operation, but it does not specify authentication requirements, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this 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 with zero waste. It is front-loaded and directly communicates the core functionality without unnecessary elaboration, making it highly concise and well-structured.

  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 simplicity (0 parameters, no output schema) and lack of annotations, the description is minimally complete. It states what the tool does but lacks details on behavior, usage, or output format. This is adequate for a basic read operation but leaves gaps in contextual understanding.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here. A baseline of 4 is applied as it adequately handles the lack of parameters without introducing confusion.

  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 all Gmail labels' clearly states the verb ('Get') and resource ('Gmail labels'), making the purpose immediately understandable. It distinguishes from siblings like 'gmail-get-email' or 'gmail-send-email' by focusing on labels rather than emails. However, it lacks specificity about scope (e.g., all labels for the authenticated user) 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?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or comparisons with sibling tools like 'gmail-read-emails' or 'gmail-get-email'. This leaves the agent without explicit direction on appropriate usage scenarios.

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

• finance-searchA
  3.8/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 mentions the query format and a note about 'SPY' returning market overview, which adds some context. However, it lacks details on permissions, rate limits, error handling, or the response structure, leaving gaps for a tool with 9 parameters.

  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 appropriately sized and front-loaded, starting with the core purpose and usage. It uses examples efficiently but could be slightly more streamlined by avoiding repetition of schema details, such as the query format examples.

  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 complexity of 9 parameters and no output schema, the description is moderately complete. It covers the main use case and query format but lacks information on return values, error cases, or advanced usage scenarios, which could hinder an agent's ability to invoke it correctly without trial and error.

  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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by reiterating the query format and examples, but does not provide additional semantic insights or clarify interactions between parameters.

  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?

  The description explicitly states the action ('Search for') and the resources ('stocks, indices, mutual funds, currencies, and futures using Google Finance'), making the purpose clear and specific. It distinguishes this tool from siblings by focusing on financial data search, unlike other tools for calendars, emails, or geography.

  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?

  The description provides clear context on when to use this tool by specifying the types of financial instruments it searches and the required query format. However, it does not explicitly state when not to use it or name alternatives, such as for non-financial searches or other data sources.

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