Greenhouse MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.4
Disambiguation3/5
The tool set covers a comprehensive range of Greenhouse operations, but there is significant overlap and ambiguity between similar tools. For example, 'add_attachment' and 'add_attachment_to_application' have unclear distinctions, and 'advance_application', 'move_application_same_job', and 'move_application' require careful reading to differentiate. While descriptions help, the sheer number of tools increases confusion, with many performing similar actions on different entities (e.g., list operations for various resources).
Naming Consistency4/5
Tool names largely follow a consistent verb_noun pattern (e.g., 'create_candidate', 'list_applications', 'update_job'), which aids predictability. However, there are minor deviations such as 'candidates_needing_action' (noun_verb) and 'source_effectiveness' (noun_noun), and some tools use underscores inconsistently (e.g., 'webhook_setup_guide' vs. 'webhook_create_rule'). Overall, the naming is mostly uniform and readable, with only a few outliers.
Tool Count2/5
With 167 tools, the count is excessive for a single MCP server, making it overwhelming and difficult to navigate. While Greenhouse is a complex platform, the tool set includes many highly specific or redundant operations (e.g., separate tools for listing various entities like 'list_board_degrees' and 'list_degrees'), which could have been consolidated. This bloated count hinders usability and suggests poor scoping, as a more focused set would improve coherence.
Completeness5/5
The tool set provides exceptionally complete coverage of the Greenhouse domain, encompassing CRUD operations for candidates, applications, jobs, interviews, users, and more, along with advanced features like pipeline analytics, bulk actions, and webhook management. There are no obvious gaps; tools support full lifecycles from prospecting to hiring, including data management, reporting, and integrations. This completeness ensures agents can handle diverse recruiting workflows without dead ends.
Average 3.2/5 across 167 of 167 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 'Create,' implying a write operation, but doesn't disclose behavioral traits such as permissions required, whether it's idempotent, rate limits, or what the output entails. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it lacks front-loading of critical details and could benefit from more structure to enhance clarity without sacrificing brevity.
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 has an output schema (which reduces the need to describe return values) but no annotations and 0% schema description coverage, the description is incomplete. It covers the basic purpose but misses key context like parameter semantics and behavioral traits, making it minimally adequate but with clear gaps.
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 schema provides no parameter descriptions. The description adds no meaning beyond the schema, failing to explain what 'job_id', 'source', or 'referrer' represent or how they should be used. This inadequately compensates for the low 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 states the action ('Create') and target ('tracking link for a job'), which clarifies the purpose. However, it doesn't differentiate from sibling tools like 'get_tracking_link' or explain what a tracking link is, making it somewhat vague. 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 'get_tracking_link' or other job-related tools. The description implies usage for creating tracking links but doesn't specify prerequisites, context, or exclusions, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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' implies a mutation operation, but the description doesn't specify what permissions are required, whether changes are reversible, what happens to unspecified fields, or any rate limits. It provides minimal behavioral context beyond the basic action.
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 sentence with no wasted words. It's front-loaded with the core action and resource. While it's too brief for adequate tool documentation, it scores perfectly on conciseness metrics.
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 5 parameters (0% schema coverage) and no annotations, the description is severely incomplete. While an output schema exists (which helps with return values), the description doesn't address critical aspects like required permissions, side effects, or parameter semantics. Given the complexity of updating webhook routing rules, this minimal description leaves too many gaps.
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?
With 0% schema description coverage for all 5 parameters, the description adds no information about what the parameters mean or how they should be used. It doesn't explain what 'rule_id' refers to, what 'event_type' and 'action_type' can be, what format 'action_url' should have, or what 'active' controls. The description fails to compensate for the complete lack of schema documentation.
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 an existing webhook routing rule' clearly states the verb ('update') and resource ('webhook routing rule'), but it's somewhat vague about what specifically gets updated. It doesn't distinguish this tool from its sibling 'webhook_create_rule' or 'webhook_delete_rule' beyond the basic action verb.
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 rule ID), when not to use it, or how it differs from related webhook tools like 'webhook_create_rule' or 'webhook_delete_rule'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Grant', implying a write operation, but doesn't clarify permissions required, whether the action is reversible, or what happens on success/failure. This leaves significant gaps in understanding the tool's behavior and potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly, 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 (a write operation with 3 parameters), no annotations, 0% schema coverage, and the presence of an output schema (which might help but isn't described), the description is inadequate. It lacks details on parameters, behavioral traits, and usage context, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (user_id, job_id, user_role_id) are documented in the schema. The description adds no information about what these parameters represent, their formats, or valid values (e.g., what user_role_id corresponds to), failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Grant') and resource ('a user a specific role on a job'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'add_future_job_permission' or 'change_user_permission_level', which could cause confusion about when to use this specific tool versus alternatives.
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 'add_future_job_permission' or 'change_user_permission_level'. It also doesn't mention prerequisites, such as whether the user or job must exist, leaving the agent without context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Change' implies a mutation operation, it doesn't specify whether this requires admin privileges, whether changes are immediate or require approval, what happens to existing permissions, or potential side effects. The description lacks critical behavioral context for a permission-modifying tool.
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 that gets straight to the point without unnecessary words. It's appropriately sized for a tool with two parameters, though it could benefit from additional context in a second sentence.
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 permission-changing tool with no annotations, 0% schema description coverage, and no output schema information provided in context signals, the description is inadequate. It doesn't explain the significance of 'global' permission level, doesn't mention authorization requirements, doesn't describe what the tool returns, and leaves both parameters poorly documented given the schema's lack of descriptions.
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 schema provides no parameter documentation. The description only mentions 'permission level' with examples but doesn't explain the 'user_id' parameter at all. It doesn't clarify what format the permission_level should be (beyond examples), whether there are constraints, or how to obtain valid user IDs. The description adds minimal value beyond the parameter names.
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 ('Change') and resource ('user's global permission level') with examples of permission levels. It distinguishes this from other user-related tools like 'update_user' or 'disable_user' by focusing specifically on permission level changes. However, it doesn't explicitly differentiate from all sibling tools that might affect permissions.
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_user' (which might also handle permissions) or 'create_user' (which sets initial permissions). There's no mention of prerequisites, required permissions, or typical use cases for changing permission levels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, not behavioral traits like permissions needed, whether it's idempotent, rate limits, or what happens on failure. It mentions optional fields but doesn't clarify defaults or constraints beyond the schema.
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 that front-loads the core action. It could be more structured by separating required vs. optional parameters, but it avoids unnecessary verbosity.
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 9 parameters, 0% schema coverage, no annotations, and an output schema (implied by context signals), the description is incomplete. It lacks behavioral context, parameter details, and doesn't leverage the output schema to explain return values, making it inadequate for safe agent 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 but only lists parameter names without explaining semantics, formats, or constraints. For example, it doesn't clarify what 'tags' are or how 'phone_numbers' should be structured, leaving 9 parameters largely undocumented.
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 'Create' and resource 'new candidate', specifying it's for creating a candidate with name and optional fields. It distinguishes from siblings like 'add_prospect' or 'post_candidate' by focusing on core candidate creation, though it doesn't explicitly contrast with them.
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 'add_prospect' or 'post_candidate', nor any prerequisites or context for usage. The description only lists parameters without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get' but does not specify if this is a read-only operation, what permissions are required, error handling, or response format. For a tool with no annotations, this leaves critical behavioral traits undefined, though it does not contradict any 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, straightforward sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
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 required parameters, no nested objects) and the presence of an output schema, the description is minimally adequate. However, with no annotations and low schema coverage, it lacks details on behavior and parameters. The output schema mitigates some gaps, but the description could be more informative for full 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 0% description coverage, with parameters 'job_id' and 'approval_flow_id' documented only by title and type. The description does not add any semantic details, such as what these IDs represent, their format, or where to obtain them. With low schema coverage, the description fails to compensate, leaving parameters inadequately explained.
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 'Get a specific approval flow for a job,' which clearly indicates a retrieval action (get) on a resource (approval flow) with a scope (for a job). However, it does not differentiate from siblings like 'list_approvals_for_job' or 'list_pending_approvals,' which might offer similar or overlapping functionality, leaving the purpose somewhat vague in context.
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 lacks context on prerequisites, such as whether the job or approval flow must exist, or comparisons to sibling tools like 'list_approvals_for_job' for broader listings. This absence of usage instructions limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 if this is a read-only operation, how results are returned (e.g., paginated, sorted), error conditions, or rate limits, leaving significant gaps for agent understanding.
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 with no wasted words, making it efficient and front-loaded. However, it's overly terse, potentially under-specifying the tool's purpose and usage, which slightly reduces its effectiveness.
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 2 parameters with no schema descriptions and an output schema present (which reduces need to explain return values), the description is minimally adequate but incomplete. It lacks details on behavior, usage context, and parameter meaning, making it insufficient for full agent understanding without external 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?
The input schema has 2 parameters with 0% description coverage, but the tool description adds no parameter information beyond what the schema provides (e.g., meaning of 'per_page' or 'page'). Since parameters are optional with defaults, the baseline is 3, but the description fails to compensate for the lack of schema descriptions.
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 action ('retrieve') and resource ('candidates submitted via the Ingestion API'), which provides a basic purpose. However, it's vague about what 'candidates' are in this context (e.g., job applicants, data entries) and doesn't distinguish from siblings like 'list_candidates' or 'retrieve_ingestion_jobs', leaving ambiguity about scope and 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?
No guidance is provided on when to use this tool versus alternatives such as 'list_candidates' or 'retrieve_ingestion_jobs'. The description lacks context about prerequisites, typical use cases, or exclusions, offering no help in tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'Update' implies a mutation operation, it doesn't disclose important behavioral traits: whether this requires specific permissions, if changes are reversible, how partial updates are handled (null values vs. omitted fields), or what the response contains. For a mutation tool with 9 parameters and no 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.
Conciseness4/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. There's no wasted language, though it could potentially benefit from additional context. The structure is appropriate for a basic tool 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?
Given the complexity (9 parameters, mutation operation), complete lack of annotations, and 0% schema description coverage, the description is inadequate. While an output schema exists (which reduces the need to describe return values), the description doesn't address critical context: behavioral traits, usage guidelines, or complete parameter semantics. For a mutation tool with this level of complexity, more comprehensive documentation is needed.
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 schema description coverage is 0%, meaning none of the 9 parameters have descriptions in the schema. The description lists some updatable fields (name, company, title, phone, email, tags, custom fields), which maps to 7 of the 9 parameters, but it doesn't explain parameter semantics like what 'phone_numbers' and 'email_addresses' arrays should contain, how 'tags' work, or what 'custom_fields' structure is expected. This partial compensation is insufficient given the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target resource ('a candidate's name, company, title, phone, email, tags, or custom fields by ID'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling update tools like update_application or update_user, which would require a 5.
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 candidate ID), when not to use it, or how it differs from related tools like create_candidate or merge_candidates. This leaves the agent with insufficient context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool generates a guide and stores a secret key, implying a read-only or informational operation. However, it lacks details on permissions needed, whether it modifies any state beyond storage, rate limits, or what the output entails. This is insufficient for a tool with potential side effects like key storage.
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 concise with two sentences that directly address the tool's function and outcome. It is front-loaded with the primary action ('Generate a setup guide') and avoids unnecessary details. However, the second sentence could be more integrated to enhance flow.
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 (2 parameters, 0% schema coverage, no annotations, but with an output schema), the description is incomplete. It omits parameter explanations, behavioral context like storage implications, and doesn't leverage the output schema to clarify return values. For a tool that generates guides and stores keys, more detail is needed to ensure 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 by explaining parameters. It does not mention 'receiver_url' or 'events' at all, leaving their purpose and usage undocumented. The description's mention of 'exact values to enter in Greenhouse UI' hints at parameter relevance but fails to specify which parameters correspond to which UI fields or how 'events' should be formatted.
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: 'Generate a setup guide for configuring a Greenhouse webhook.' It specifies the verb ('Generate') and resource ('setup guide'), and distinguishes it from siblings by focusing on webhook configuration guidance rather than direct webhook operations (e.g., webhook_create_rule). However, it doesn't explicitly differentiate from all siblings, as some may also involve guidance or documentation.
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 mentions storing a secret key, but doesn't specify prerequisites, when to use it over direct webhook tools (e.g., webhook_create_rule), or any exclusions. Without such context, users may struggle to apply it correctly in workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 lacks behavioral details. It states the action but doesn't disclose permissions required, whether this is a mutating operation (implied by 'Attach'), rate limits, error conditions, or what happens on success (e.g., attachment ID returned). This is inadequate for a tool with potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and methods, making it easy to parse quickly. Every word earns its place by conveying 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?
Given the tool's complexity (6 parameters, mutation operation) and lack of annotations, the description is incomplete. While an output schema exists (which helps), the description doesn't address key contextual gaps like authentication needs, error handling, or practical usage examples. For a mutating tool with multiple parameters, this leaves significant uncertainty for an agent.
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 but adds minimal param semantics. It mentions 'base64 content or URL' which hints at 'content' and 'url' parameters, but doesn't explain the 'type' parameter, required 'application_id' and 'filename', or optional 'content_type'. The description fails to clarify parameter relationships or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach a file') and target resource ('to an application'), specifying two attachment methods ('via base64 content or URL'). It distinguishes from sibling tools like 'download_attachment' by focusing on creation rather than retrieval, though it doesn't explicitly differentiate from 'add_attachment' which might be a more generic version.
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. It doesn't mention prerequisites (e.g., needing an existing application), exclusions (e.g., file size limits), or comparisons to similar tools like 'add_attachment' or 'add_email_note_to_candidate', leaving the agent to 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.
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 states 'Create a new prospect' which implies a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether it triggers notifications, if duplicates are allowed, or what happens on failure. For a creation 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 that front-loads the core action ('Create a new prospect') and mentions key parameters. There's zero waste or redundancy. It's appropriately sized for a tool description, though the 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 complexity (9 parameters, creation/mutation operation) with no annotations and 0% schema description coverage, the description is incomplete. While an output schema exists (which helps), the description doesn't address critical context like required permissions, error conditions, or how this tool relates to the many sibling creation tools. For a prospect creation tool in what appears to be an ATS/CRM system, this leaves too many questions unanswered.
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 mentions 'name and optional pool, stage, and owner assignment' which covers only 4 of the 9 parameters (first_name/last_name as 'name', plus three optional IDs). It omits company, title, phone_numbers, and email_addresses entirely, leaving most parameters undocumented. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new prospect', specifying it's for adding prospects to a system. It mentions key fields like name and optional assignments, which helps distinguish it from generic creation tools. However, it doesn't explicitly differentiate from sibling tools like 'create_candidate' or 'post_candidate', which might have overlapping purposes in a CRM/ATS context.
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 many sibling tools like 'create_candidate', 'post_candidate', and 'convert_prospect', there's no indication of prerequisites, dependencies, or scenarios where 'add_prospect' is preferred. This leaves the agent guessing about the tool's specific role in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a mutation operation ('anonymize') but does not specify whether this is reversible, what permissions are required, how it affects data integrity, or any rate limits. The mention of GDPR/compliance hints at legal implications but lacks operational details, 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 a single, efficient sentence that directly states the tool's purpose without redundancy. It is front-loaded with the core action and context, making it easy to parse quickly, with no wasted words.
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 mutation tool with GDPR implications, no annotations, 0% schema coverage, and 2 parameters, the description is inadequate. It lacks details on behavior, parameter usage, output (though an output schema exists, the description doesn't hint at it), and integration with sibling tools, leaving critical gaps for effective tool invocation.
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 schema provides no parameter descriptions. The description mentions 'specific fields' but does not clarify what 'fields' parameter entails (e.g., which fields are anonymizable, format, or examples) or the 'candidate_id' usage. It adds minimal semantic value beyond the parameter names, failing to compensate for the low 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 action ('anonymize') and target ('specific fields on a candidate'), with a specific purpose ('for GDPR/privacy compliance'). However, it does not explicitly differentiate from sibling tools like 'update_candidate' or 'delete_candidate', which might also handle candidate data modifications, leaving some ambiguity about its unique role.
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 (e.g., 'update_candidate' for non-anonymizing changes or 'delete_candidate' for removal). It mentions GDPR/privacy compliance as a context but does not specify prerequisites, constraints, or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Create a new job', implying a write operation, but does not cover permissions, side effects, rate limits, or response format. This is inadequate for a mutation tool with zero annotation coverage, missing critical behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and lists key optional parameters without waste. It is appropriately sized for the tool's complexity, earning full marks 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 7 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on required parameters, behavioral traits, and full parameter semantics, making it inadequate for proper tool invocation in this 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?
Schema description coverage is 0%, so the description must compensate. It mentions optional 'name, department, and offices', which partially maps to parameters like 'job_name', 'department_id', and 'office_ids', but omits 'template_job_id' (required), 'number_of_openings', 'job_post_name', and 'requisition_id'. This leaves most parameters undocumented, failing to add sufficient meaning.
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 a new job') and resource ('from a template'), and mentions optional fields. It distinguishes from siblings like 'create_job_opening' by focusing on template-based creation, though not explicitly. However, it lacks specific differentiation from all siblings, keeping it at 4.
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 'create_job_opening' or 'update_job'. It mentions optional parameters but does not specify prerequisites, exclusions, or context for selection among siblings, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool deletes options, implying a destructive mutation, but doesn't disclose behavioral traits like whether deletions are permanent, require specific permissions, affect existing data (e.g., applications using those options), or have rate limits. The description is minimal and lacks critical context for a mutation 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. 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 no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on behavior, parameters, usage context, and error conditions. While the output schema may cover return values, the description doesn't provide enough context 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 schema provides no parameter descriptions. The description mentions 'option IDs' but doesn't explain what 'custom_field_id' is, where to find these IDs, or the format/constraints (e.g., integer ranges). It adds minimal semantics beyond the parameter names, failing to compensate for the coverage gap.
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 specific options') and resource ('from a dropdown/multi-select custom field'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_custom_field' or 'update_custom_field_options', which handle related but different operations.
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., whether the custom field must exist), exclusions (e.g., cannot delete all options), or sibling tools like 'delete_custom_field' for removing the entire field or 'update_custom_field_options' for modifying options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get', implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or what happens if the IDs are invalid. 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 no wasted words. It's front-loaded and appropriately sized for the tool's apparent simplicity, making it easy 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 simple parameters) and the presence of an output schema (which reduces the need to describe return values), the description is somewhat complete but lacks critical context. Without annotations and with no parameter semantics, it's minimally viable but leaves gaps in usage and behavior that could hinder correct tool 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?
The description adds no meaning beyond the input schema, which has 0% description coverage. It doesn't explain what 'job_id' and 'opening_id' represent or how to obtain them. With 2 parameters and low schema coverage, the baseline is 3 because the schema defines the parameters structurally, but the description fails to compensate with semantic details.
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 specific opening on a job' clearly states the action (get) and resource (opening on a job), but it's vague about what 'opening' means in this context (e.g., job opening vs. other types) and doesn't differentiate from sibling tools like 'get_job' or 'list_job_openings', which could cause confusion. It's adequate 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. For example, it doesn't specify if this is for retrieving details of a single opening versus listing multiple openings (as in 'list_job_openings') or getting job-level information ('get_job'). The description offers no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a read operation ('Get') but lacks details on permissions, rate limits, error handling, or output format. This is inadequate for a tool with no annotation coverage, as it omits critical behavioral traits.
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 no wasted words. It's front-loaded and efficiently conveys the core action, making it highly concise and well-structured for quick understanding.
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 parameter) and the presence of an output schema, the description is minimally complete. However, with no annotations and a vague purpose, it lacks depth for full contextual understanding, though the output schema mitigates some 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?
The description doesn't add any parameter information beyond the input schema, which has 0% description coverage. Since there's only one parameter and the schema defines it as an integer 'section_id', the baseline is 3—adequate given minimal parameters but no extra semantic context provided.
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 verb ('Get') and resource ('a single prospect post section'), which clarifies the basic purpose. However, it's vague about what a 'prospect post section' is and doesn't differentiate from sibling tools like 'list_prospect_post_sections' or 'get_job_post', missing specificity for clear 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context for use, or compare to sibling tools such as 'list_prospect_post_sections', leaving the agent without 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.
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 this is a list operation, implying read-only behavior, but doesn't mention pagination behavior (despite pagination parameters in schema), rate limits, authentication needs, or what 'all EEOC data' entails. For a tool with pagination parameters and no annotation coverage, this is insufficient.
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 front-loaded with the core purpose and appropriately sized for a list operation, though this conciseness comes at the cost of missing important details.
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 has an output schema (which helps), no annotations, and 3 parameters with 0% schema coverage, the description is incomplete. It doesn't explain pagination behavior, return format, or usage context. For a list tool with pagination parameters, this leaves significant gaps in understanding how to effectively use it.
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 for undocumented parameters. It mentions 'all EEOC data' but provides no information about the three pagination parameters (per_page, page, paginate) or their semantics. The description adds no value beyond what's inferred from the tool name, failing to address the parameter gap.
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 EEOC data collected from applications'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_eeoc_for_application' which appears to retrieve EEOC data for a specific application, 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 like 'get_eeoc_for_application' or other list tools. It lacks context about prerequisites, appropriate scenarios, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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's a list operation, implying read-only behavior, but doesn't disclose pagination behavior (despite pagination parameters in the schema), rate limits, authentication needs, or what 'force_refresh' entails. This leaves significant behavioral gaps for a tool with multiple 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 zero waste. It's front-loaded and appropriately sized for a basic list tool, though its 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 complexity (4 parameters with 0% schema coverage, no annotations, but an output schema exists), the description is incomplete. It doesn't address parameter meanings, behavioral traits like pagination, or usage context. The output schema mitigates the need to explain return values, but other gaps remain significant.
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 schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description adds no parameter information beyond implying it lists offices, failing to explain 'per_page', 'page', 'paginate', or 'force_refresh'. With low coverage, the description should compensate but doesn't.
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 offices in the organization'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_office' (which likely retrieves a single office) or 'list_board_offices' (which might have a different scope), 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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose 'list_offices' over 'get_office' (for a single office) or 'list_board_offices' (which might be board-specific), nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List all' which implies a read operation, but doesn't disclose pagination behavior (despite page/per_page parameters), caching implications (force_refresh parameter), authentication requirements, rate limits, or what 'all' means in practice. For a tool with 3 parameters and no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. The parenthetical examples add helpful context without unnecessary elaboration. However, it could be slightly improved by front-loading the most critical information more explicitly.
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?
The tool has an output schema (which reduces the need to describe return values), but with 3 parameters at 0% schema coverage and no annotations, the description should do more to explain parameter usage and behavioral context. The description is minimally adequate for a simple list operation but leaves important questions unanswered about pagination and refresh behavior.
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 for undocumented parameters. The description mentions 'List all' but doesn't explain the pagination parameters (page, per_page) or the force_refresh parameter. With 3 parameters completely undocumented in both schema and description, this represents a significant gap in 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 verb ('List') and resource ('candidate sources'), providing specific examples (job boards, referrals, agencies) that help clarify the domain. However, it doesn't explicitly distinguish this tool from other list_* siblings in the extensive sibling list, which would require a 5.
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, prerequisites, or context for usage. With many other list_* tools available (list_candidates, list_jobs, list_departments, etc.), the absence of any differentiation guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 retrieval via the Ingestion API but doesn't cover key traits like whether it's read-only (implied by 'retrieve'), pagination behavior (though parameters hint at it), rate limits, authentication needs, or error handling. For a tool with no annotations, 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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, which aligns well with the conciseness dimension.
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 has an output schema (which reduces the need to describe return values), no annotations, and low parameter complexity, the description is somewhat complete but lacks depth. It covers the basic purpose but misses usage guidelines, behavioral details, and parameter explanations, making it minimally viable but with clear gaps for effective 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 input schema has two parameters ('per_page' and 'page') with 0% description coverage, meaning the schema provides no semantic details. The description doesn't add any meaning to these parameters beyond what's implied by their names (e.g., it doesn't explain default values, ranges, or how they affect retrieval). However, with only two parameters and a baseline of 3 due to minimal complexity, the score reflects adequate but uninformative handling.
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's purpose as 'Retrieve jobs visible to the partner via Ingestion API,' which includes a verb ('Retrieve') and resource ('jobs'). However, it's somewhat vague about what 'jobs' specifically refers to (e.g., ingestion jobs, processing jobs) and doesn't distinguish it from sibling tools like 'list_jobs' or 'retrieve_ingestion_candidates,' which could lead to confusion in selection.
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 lacks context such as prerequisites, when it's appropriate compared to other job-related tools (e.g., 'list_jobs'), or any exclusions. This absence makes it harder for an agent to decide correctly without additional inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'Update' implies a mutation operation, the description doesn't disclose important behavioral traits like required permissions, whether changes are reversible, what happens to existing fields not mentioned, rate limits, or what the response contains. This is inadequate 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 a single, efficient sentence with zero wasted words. It's appropriately sized for what it communicates and front-loads the essential 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 mutation tool with 4 parameters, 0% schema coverage, no annotations, and many sibling tools, the description is incomplete. While an output schema exists (which reduces the need to describe return values), the description doesn't adequately cover usage context, parameter meanings, or behavioral implications needed for safe and correct tool invocation.
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?
With 0% schema description coverage and 4 parameters, the description only mentions 'source, referrer, or custom fields' which partially maps to 3 parameters. It doesn't mention the required 'application_id' parameter at all, nor does it explain what these fields represent, their formats, or constraints. The description adds minimal value beyond the parameter names visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an application') with specific fields mentioned ('source, referrer, or custom fields'). It distinguishes from siblings like 'update_candidate' or 'update_job' by focusing on applications, but doesn't explicitly differentiate from other application-related update 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 is provided on when to use this tool versus alternatives. With siblings like 'update_candidate', 'advance_application', and 'move_application', the description doesn't indicate when this specific update operation is appropriate versus other modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a mutation ('Update'), but doesn't disclose behavioral traits such as required permissions, whether this overwrites or merges options, error handling, or rate limits. This is inadequate 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 a single, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for the tool's complexity, 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 mutation nature, lack of annotations, 0% schema coverage, and no output schema explanation in the description, it's incomplete. The description doesn't address key aspects like what the update entails, response format, or error conditions, leaving significant gaps for an AI agent.
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 schema provides no parameter details. The description mentions 'options' but doesn't explain what they are (e.g., array of objects with 'id' and 'value') or the purpose of 'custom_field_id'. It adds minimal meaning beyond the bare schema, failing to compensate for the coverage gap.
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 options on a dropdown/multi-select custom field'), making the purpose evident. However, it doesn't explicitly distinguish this tool from sibling tools like 'create_custom_field_options' or 'delete_custom_field_options', which would require mentioning creation or deletion to differentiate.
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 custom field), exclusions (e.g., not for single-select fields), or refer to sibling tools like 'create_custom_field_options' for initial setup or 'list_custom_field_options' for viewing current options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Update' implies a mutation operation but doesn't specify permissions required, whether changes are reversible, error handling (e.g., for invalid times), or rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
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 is front-loaded with the core action and resource, making it easy to parse quickly, though it could benefit from additional context for completeness.
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 (mutation with 4 parameters, no annotations, and 0% schema coverage), the description is inadequate. It lacks details on behavioral traits, parameter meanings, and usage guidelines. While an output schema exists (which might cover return values), the description doesn't address critical aspects like error conditions or dependencies, making it incomplete 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 schema provides no parameter descriptions. The description mentions 'start time, end time, or interviewers,' which hints at parameters like 'start', 'end', and 'interviewer_ids', but doesn't explain semantics (e.g., date formats, null handling, or that 'interview_id' is required). It fails to compensate for the low coverage, leaving parameters largely undocumented.
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 ('Update') and resource ('a scheduled interview') with specific fields ('start time, end time, or interviewers'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'create_interview' or 'delete_interview', though the verb 'Update' implies modification of existing records versus creation or deletion.
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 (e.g., 'create_interview' for new interviews, 'delete_interview' for removal, or other update tools like 'update_application'). It lacks context on prerequisites, such as needing an existing interview ID, or exclusions, leaving the agent to 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.
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 states this is an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether updates are partial or complete, if changes are reversible, rate limits, or what happens to unspecified fields. 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 that directly states the tool's purpose. It's appropriately sized and front-loaded with no wasted words, 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 this is a mutation tool with 4 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is incomplete. It doesn't explain the required job_post_id parameter, doesn't provide usage context among many sibling update tools, and lacks behavioral transparency needed for safe operation. The output schema helps with return values, but the description should do more.
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 mentions three parameters (title, location, content) but doesn't explain the fourth parameter (job_post_id) or provide any semantic context beyond field names. No details are given about parameter formats, constraints, or how null values are handled for optional fields.
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 the resource 'job post', specifying the fields that can be modified (title, location, content). It distinguishes from siblings like 'update_job_post_status' which focuses on status changes rather than content updates. However, it doesn't explicitly differentiate from other update tools like 'update_job' or 'update_job_opening'.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a job_post_id), nor does it clarify if this should be used instead of other update tools for job-related modifications. The sibling list includes many update tools, but no context is given for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool logs an email interaction, implying a write operation, but doesn't disclose behavioral traits such as permissions needed, whether it's idempotent, rate limits, or what the activity feed looks like. 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 a single, efficient sentence that front-loads the core purpose and key parameters. Every word earns its place with no redundancy or fluff, making it easy 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 has an output schema (which covers return values), no annotations, and 5 parameters with 0% schema coverage, the description is moderately complete. It specifies the action and parameters but lacks behavioral context and detailed parameter semantics, making it adequate but with clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the parameters (to, from, subject, body, and implies candidate_id via context), adding meaning beyond the bare schema. However, it doesn't explain parameter formats (e.g., email addresses for 'to' and 'from_'), constraints, or examples, leaving gaps in 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 action ('Log an email interaction') and the target ('on a candidate's activity feed'), with specific fields involved. It distinguishes from sibling tools like 'add_note_to_candidate' by specifying email-specific fields, though it doesn't explicitly contrast with 'add_email_to_user' which might serve a different 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?
No guidance is provided on when to use this tool versus alternatives like 'add_note_to_candidate' or 'add_email_to_user'. The description implies usage for logging email interactions but lacks context about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Apply a tag' implies a write/mutation operation, but the description doesn't mention permission requirements, whether the operation is idempotent, error conditions (e.g., invalid IDs), or what happens if the tag is already applied. For a mutation tool with zero annotation coverage, this represents 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 a simple operation.
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 moderate complexity (2 required parameters, mutation operation) and the presence of an output schema (which reduces need to describe return values), the description is minimally adequate but incomplete. It lacks parameter explanations, usage context, and behavioral details that would be helpful despite the output schema. The conciseness is good, but other dimensions show significant gaps.
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%, meaning neither parameter has any documentation in the schema. The description mentions 'tag' and 'candidate' but doesn't explain what 'candidate_id' and 'tag_id' represent, their format, or where to obtain them. While it hints at the parameters' purpose, it fails to provide meaningful semantic details beyond the obvious.
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 ('Apply a tag') and target resource ('to a candidate'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'bulk_tag' or 'remove_tag_from_candidate', which prevents a perfect score, but the verb+resource combination is specific enough for basic understanding.
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 about when to use this tool versus alternatives like 'bulk_tag' for multiple candidates or 'create_tag' for tag creation. There's no mention of prerequisites (e.g., existing tag and candidate) or context for application, leaving the agent with insufficient usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'convert' implies a state change operation, it doesn't disclose whether this requires specific permissions, whether it's reversible, what happens to the original prospect data, or any rate limits. The description provides minimal behavioral context beyond the basic action.
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 states the core purpose without unnecessary words. It's appropriately sized for a tool with two parameters and follows a clear subject-verb-object structure.
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?
While the tool has an output schema (which reduces the need to describe return values), the description is inadequate for a state-changing operation with no annotations and undocumented parameters. It covers the basic purpose but lacks crucial context about behavior, parameter meaning, and usage guidelines that would be needed for reliable tool invocation.
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?
With 0% schema description coverage for both parameters, the description provides no information about what 'application_id' and 'job_id' represent, their format constraints, or how they relate to the conversion process. The description doesn't compensate for the complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('convert') and the target resources ('prospect application to a candidate application on a specific job'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar sibling tools like 'advance_application' or 'create_candidate', which might handle related workflow transitions.
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, prerequisites, or exclusions. Given the many sibling tools for managing applications and candidates, this lack of contextual guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Create an application,' implying a write operation, but doesn't disclose any behavioral traits such as required permissions, whether it's idempotent, what happens on conflicts, or the response format. This leaves significant gaps for an agent to understand how to use it safely and effectively.
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 ('Create an application for a candidate on a job') and adds necessary detail ('with optional source and referrer') without any wasted words. It's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to explain return values) but no annotations and 0% schema description coverage, the description is incomplete. It covers the basic purpose but lacks crucial details like behavioral traits, parameter meanings, and usage context, making it only minimally viable for an agent to operate effectively.
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 for the lack of parameter documentation. It mentions 'optional source and referrer,' which hints at two parameters (source_id and referrer), but doesn't explain the semantics of the six parameters (e.g., what candidate_id and job_id represent, the purpose of initial_stage_id or attachments). This adds minimal value beyond the schema's structure.
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 an application') and specifies the target resources ('for a candidate on a job'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'submit_application' or 'post_candidate', which might have overlapping functionality in the same domain.
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 mentions optional parameters ('with optional source and referrer'), which gives some context about when to provide additional data, but it doesn't offer guidance on when to use this tool versus alternatives like 'submit_application' or 'create_candidate', nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Add new options' implies a write operation, it doesn't specify whether this requires special permissions, whether it's idempotent, what happens if options already exist, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 target, making it immediately scannable and understandable without unnecessary elaboration.
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 that there's an output schema (which handles return values) and only 2 parameters, the description covers the basic purpose adequately. However, for a mutation tool with no annotations and poor schema documentation, it should provide more behavioral context and parameter guidance to be truly complete for agent 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?
With 0% schema description coverage for both parameters, the description provides minimal help. It mentions 'dropdown/multi-select custom field' which hints at the 'custom_field_id' purpose, and 'options' which maps to the array parameter name, but doesn't explain what an option object should contain, format requirements, or constraints. The description doesn't adequately compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add new options') and target resource ('to a dropdown/multi-select custom field'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_custom_field' or 'update_custom_field_options', which would be needed for 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 'create_custom_field' (for creating the field itself) or 'update_custom_field_options' (which appears to modify existing options). There's no mention of prerequisites, constraints, or appropriate contexts for this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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's a creation tool, implying mutation, but lacks critical details like required permissions, whether the operation is idempotent, what happens on duplicate names, or error conditions. The description is minimal and doesn't compensate for the absence 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 that front-loads the core purpose without any wasted words. Every part of the sentence contributes directly to understanding the tool's function and parameters.
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, 0% schema coverage, and the tool being a mutation operation, the description is inadequate. It lacks behavioral context, error handling, permissions, and output expectations (though an output schema exists, the description doesn't hint at what it returns). For a creation tool in a system with many siblings, more completeness is needed.
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 0%, so the description must compensate. It mentions both parameters ('name' and 'optional parent department'), which aligns with the two parameters in the schema. However, it doesn't add meaningful semantics beyond naming them—no format expectations, constraints, or examples. This provides basic mapping but insufficient detail for a tool with zero schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new department') and specifies the key attributes ('with a name and optional parent department'), making the purpose immediately understandable. It distinguishes from siblings like 'update_department' by focusing on creation, though it doesn't explicitly contrast with other creation tools like 'create_office' or 'create_user'.
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, prerequisites, or constraints. It doesn't mention when to choose this over other department-related tools like 'update_department' or 'list_departments', leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Schedule an interview' which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether scheduling is reversible, potential conflicts with existing interviews, rate limits, or what happens on success/failure. The description is minimal and lacks crucial operational 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 front-loads the core purpose. Every word contributes directly to explaining what the tool does without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) but no annotations and 0% schema description coverage, the description is incomplete. It adequately states the basic purpose but lacks usage guidelines, behavioral context, and full parameter semantics needed for a mutation tool with 5 required parameters.
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 parameters are undocumented in the schema. The description mentions 'interviewers and a start/end time' which partially covers 3 of the 5 parameters (interviewer_ids, start, end), but doesn't explain application_id or interview_id at all. It fails to compensate for the schema gap, leaving key parameters unexplained.
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 ('Schedule an interview') and specifies the resource ('for an application') along with key components ('with interviewers and a start/end time'). It distinguishes from siblings like 'update_interview' or 'delete_interview' by focusing on creation, but doesn't explicitly differentiate from other scheduling-related tools in the sibling list.
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., existing application, available interviewers), exclusions, or refer to sibling tools like 'list_interviews_for_application' for checking existing interviews before scheduling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 or replaces an approval flow, implying a mutation operation, but lacks critical details: whether it requires specific permissions, if it's idempotent ('replace' suggests possible overwriting), what happens on failure, or rate limits. 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 front-loads the core action and key parameters, making it easy to parse quickly. Every element ('create or replace', 'approval flow', 'job', 'type and approver groups') earns its place by conveying essential information.
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 complexity (mutation with 3 parameters) and lack of annotations, the description is minimally adequate but incomplete. It identifies the resource and main parameters, and an output schema exists (which may cover return values), reducing the burden. However, it misses behavioral details (e.g., side effects, error handling) and full parameter semantics, leaving gaps 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%, meaning parameters are undocumented in the schema. The description mentions 'type and approver groups', which partially covers two of the three parameters (approval_type, approver_groups), but omits 'job_id' entirely. It doesn't explain what approval types are valid, the structure of approver groups, or how job_id is used, leaving key semantics unclear.
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 or replace') and resource ('approval flow for a job'), making the purpose evident. It specifies the target (job) and key parameters (type and approver groups), which helps distinguish it from general creation tools. However, it doesn't explicitly differentiate from sibling tools like 'get_approval_flow' or 'list_approvals_for_job', which would require a 5.
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., existing job), exclusions, or compare it to similar tools like 'update' operations. Without such context, users must infer usage from the name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Delete' implies a destructive operation, it doesn't specify whether this action is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting related records). For a destructive tool with zero annotation coverage, this represents a significant transparency 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 appropriately sized for a simple delete operation and front-loads the essential information (action + target). Every word earns its place.
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 operation with no annotations, 0% schema description coverage, and multiple sibling deletion tools, the description is inadequate. It doesn't address critical context like permanence, permissions, error conditions, or relationship to other tools. The presence of an output schema helps somewhat, but the description should do more given the tool's complexity and risk profile.
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 'by ID' which aligns with the single 'application_id' parameter in the schema. However, with 0% schema description coverage, the description doesn't add meaningful details about parameter format, constraints, or where to obtain the ID. It provides minimal semantic value beyond what's implied by the parameter name itself.
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 target resource ('an application by ID'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'delete_candidate' or 'delete_job_opening', but the specificity of 'application' provides adequate differentiation within this context.
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 'reject_application' or 'delete_candidate', nor does it mention prerequisites (e.g., needing application ID from 'get_application' or 'list_applications'). It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'Delete' implies a destructive operation, the description doesn't specify whether this action is permanent, reversible, requires specific permissions, or what happens to associated data (applications, notes, etc.). For a destructive 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 and resource, making it immediately scannable and understandable.
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 operation with no annotations and minimal parameter guidance, the description is inadequate. While an output schema exists (which reduces the need to describe return values), the description fails to address critical behavioral aspects like permanence, permissions, or side effects that are essential for safe tool 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?
The description mentions 'by ID' which aligns with the single 'candidate_id' parameter in the schema. However, with 0% schema description coverage, the description doesn't add meaningful details about parameter format, constraints, or where to find candidate IDs. It provides minimal value beyond what's implied by the parameter name.
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 resource ('a candidate by ID'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'delete_application' or 'delete_tag', but the specificity of 'candidate' provides adequate differentiation within the context of candidate management 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?
The description provides no guidance on when to use this tool versus alternatives like 'anonymize_candidate' or 'merge_candidates', nor does it mention prerequisites or consequences. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Delete' implies a destructive mutation, but it doesn't disclose behavioral traits such as permissions required, whether deletion is permanent or reversible, effects on associated data, or error handling. This is inadequate for a destructive 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 a single, direct sentence with zero wasted words. It's front-loaded and efficiently conveys the core action 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, 0% schema description coverage, and an output schema (which helps but isn't described), the description is insufficient. It lacks critical context like safety warnings, prerequisites, and behavioral details, making it incomplete for safe and 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 0%, but the description adds minimal semantics by specifying 'by ID', which clarifies the parameter's role. However, it doesn't explain the ID format, source, or validation, leaving gaps. With one parameter and no schema descriptions, baseline 3 is appropriate as it provides some context.
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 resource ('a custom field by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'delete_custom_field_options' or 'delete_tag', which follow the same pattern, so it's not fully distinctive.
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 the custom field ID from 'list_custom_fields'), exclusions, or related tools like 'update_custom_field' or 'create_custom_field' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get' implies a read operation, but doesn't clarify if it's safe, requires permissions, has rate limits, or what the output contains. For a tool with no annotations, this leaves significant behavioral gaps, though it's not contradictory.
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 no wasted words. It's front-loaded with the core action and scope, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
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 simple parameters) and the presence of an output schema (which handles return values), the description is somewhat complete for basic understanding. However, with no annotations and 0% schema coverage, it lacks details on behavior and parameters, making it only minimally adequate.
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%, meaning parameters are undocumented in the schema. The description mentions 'scoped to a particular job', hinting at job_id, but doesn't explain job_post_id or their relationship. It adds minimal value beyond the schema, failing to compensate for the low coverage, though it's not entirely absent.
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 specific job post', with the scope 'scoped to a particular job'. It distinguishes this tool from siblings like 'get_job_post' (which lacks job scoping) and 'list_job_posts_for_job' (which lists multiple posts). However, it doesn't explicitly contrast with these siblings, keeping 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 like 'get_job_post' or 'list_job_posts_for_job'. It lacks context about prerequisites, such as needing both job_id and job_post_id, or when this tool is preferred over a list operation for a single post. Without such direction, usage is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a mutation ('Mark as hired') but lacks details on permissions required, whether the action is reversible, side effects (e.g., notifications), or error conditions. This leaves significant gaps for safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and lists optional parameters without unnecessary words. It earns its place by conveying essential information compactly.
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 mutation nature, no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It covers the basic action but misses critical behavioral context like permissions or side effects, making it minimally adequate but with clear gaps for safe 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 mentions optional parameters ('start date, opening, and close reason') but doesn't explain their meanings, formats (e.g., date string format), or how they affect the hiring process. This adds minimal value beyond the schema's parameter names.
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 ('Mark an application as hired') and the resource ('application'), making the purpose evident. It distinguishes from siblings like 'advance_application' or 'reject_application' by specifying the hiring outcome, though it doesn't explicitly contrast with them.
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 'advance_application' or 'update_application', nor does it mention prerequisites such as application state or permissions. It only lists optional parameters without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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's a list operation (implying read-only), but doesn't mention authentication requirements, rate limits, pagination behavior (despite pagination parameters in schema), or what 'all' means in practice (e.g., time range limitations). This leaves significant gaps for a tool with pagination 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, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core purpose 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 has an output schema (which handles return values) and relatively simple parameters, the description covers the basic purpose adequately. However, with no annotations and 0% schema description coverage, it should provide more guidance about pagination behavior and usage context to be truly complete.
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 for undocumented parameters. It mentions no parameters at all, failing to explain the purpose of 'per_page', 'page', and 'paginate' parameters that appear in the schema. This leaves the agent guessing about how to control pagination.
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 ('demographic survey answers submitted by candidates'), making the purpose unambiguous. It distinguishes from siblings like 'list_answers_for_application' by specifying 'all' answers rather than application-specific ones, though it doesn't explicitly name alternatives.
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 'list_answers_for_application' or 'get_answer'. It doesn't mention prerequisites, filtering capabilities, or any contextual constraints, leaving the agent with insufficient usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'List all' implies a read-only operation, the description doesn't mention pagination behavior (despite pagination parameters in the schema), caching/refresh implications (relevant to the 'force_refresh' parameter), or any rate limits or authentication requirements. For a tool with parameters affecting behavior, this is insufficient.
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 states the core purpose without unnecessary words. It's front-loaded with the essential information ('List all degree types') and doesn't waste space on redundant or vague phrasing. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (per context signals), the description doesn't need to explain return values. However, for a tool with 3 parameters (all undocumented in schema) and no annotations, the description is too minimal—it doesn't address parameter usage, behavioral constraints, or differentiation from siblings. It's adequate for basic understanding but lacks completeness for effective tool selection and invocation.
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 schema provides no parameter documentation. The description mentions no parameters at all, failing to explain what 'per_page', 'page', or 'force_refresh' mean or how they affect the listing. With 3 undocumented parameters, the description adds zero semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all') and the resource ('degree types available for candidate education records'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar list tools in the sibling set (like list_board_degrees, list_schools, list_disciplines), which would require explicit differentiation to earn a 5.
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 many similar list tools in the sibling set (e.g., list_board_degrees, list_schools), there's no indication of when this specific degree list is appropriate versus other degree-related tools. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'List' implies a read-only operation, it doesn't mention pagination behavior (implied by parameters), caching/refresh implications, authentication requirements, rate limits, or what the output contains. For a tool with 4 parameters and no annotation coverage, 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 with no wasted words. It's front-loaded with the core purpose and efficiently communicates the basic action without unnecessary elaboration.
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 (a simple list operation) and the presence of an output schema (which should document return values), the description is minimally adequate for the core purpose. However, the complete lack of parameter documentation and behavioral context makes it insufficient for effective use without external knowledge.
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%, meaning none of the 4 parameters are documented in the schema. The description adds no information about parameters like 'per_page', 'page', 'paginate', or 'force_refresh', leaving their purpose and usage completely unexplained. This fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all departments in the organization'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_board_departments' or 'get_department', which might serve similar but distinct 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. With sibling tools like 'list_board_departments' and 'get_department' available, there's no indication of how this tool differs in scope, context, or intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List all' but doesn't disclose behavioral traits like pagination behavior (implied by parameters), rate limits, authentication requirements, or whether the data is cached (hinted by 'force_refresh' parameter). The description is minimal and lacks operational 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 front-loads the core purpose. There's no wasted verbiage or redundant information, making it easy 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 has an output schema (which handles return values), the description's minimalism is partially excused. However, with 3 parameters at 0% schema coverage and no annotations, the description should provide more context about parameter usage and behavioral expectations to be fully complete for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about the three parameters (per_page, page, force_refresh) beyond what the schema titles imply. No explanation of parameter purposes, defaults, or effects is provided 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 ('List all') and resource ('academic disciplines'), with specific context ('available for candidate education records'). However, it doesn't differentiate from sibling tools like 'list_board_disciplines' or 'list_degrees', which appear to serve similar listing functions in the same domain.
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 'list_board_disciplines' or 'list_degrees'. The description implies a specific context ('for candidate education records') but doesn't clarify if this is exclusive or how it differs from other discipline-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'List all' implies a read-only operation, it doesn't address pagination behavior (despite pagination parameters in the schema), rate limits, authentication requirements, or what 'available in the organization' means operationally. This leaves significant gaps for a tool with three 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, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core purpose 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 that an output schema exists, the description doesn't need to explain return values. However, for a tool with three parameters and no annotations, the description is too minimal—it doesn't address parameter usage, behavioral constraints, or differentiation from siblings. It's adequate for basic understanding but has clear gaps.
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 schema provides no parameter descriptions. The tool description doesn't mention any parameters at all, failing to compensate for the complete lack of schema documentation. Parameters like 'force_refresh' have unclear semantics without explanation.
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 ('List all') and resource ('email templates available in the organization'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from potential siblings like 'get_email_template' (singular) or other list tools, 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, appropriate contexts, or exclusions, leaving the agent to 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.
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. While 'List' implies a read operation, it doesn't disclose important behavioral aspects: whether this requires authentication, what permissions are needed, if there are rate limits, what format the date filters use, or how pagination works. The description mentions date filters but doesn't explain their behavior or format.
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 perfectly concise - a single sentence that communicates the core functionality upfront. Every word earns its place, with no redundant information or unnecessary elaboration. The structure is front-loaded with the main purpose.
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 that there's an output schema (which handles return values) but no annotations and poor parameter documentation, the description is minimally adequate. It states what the tool does but lacks crucial context about authentication, permissions, pagination behavior, and date formats. For a listing tool with pagination parameters, more guidance would be helpful.
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?
With 0% schema description coverage for 5 parameters, the description only mentions 'optional created date range filters' (covering created_after/created_before). It ignores pagination parameters (per_page, page, paginate) entirely. For a tool with 5 undocumented parameters, this minimal coverage is insufficient - the description should explain pagination behavior and date format expectations.
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 scheduled interviews'), making the purpose immediately understandable. It also mentions optional date range filters, which adds specificity. However, it doesn't explicitly differentiate this tool from similar siblings like 'list_interviews_for_application' or 'get_interview', which would require a 5.
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 multiple interview-related tools in the sibling list (list_interviews_for_application, get_interview), there's no indication of when this general listing tool is preferred over more specific ones. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it's a list operation but doesn't mention pagination behavior (implied by parameters), rate limits, authentication requirements, or what the output contains. For a list tool with pagination parameters, this leaves significant gaps in understanding 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 that states the core purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation) and the existence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and poor parameter documentation, it leaves the agent with insufficient context about pagination behavior and usage scenarios. It meets the bare minimum but has clear gaps.
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 no parameters, while the schema has 3 parameters with 0% description coverage. Parameters like 'paginate' (with default 'single') and pagination controls ('per_page', 'page') are completely undocumented in the description. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all job stages across all jobs'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'list_job_stages_for_job', which suggests a more specific scope. The description is clear but lacks 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. There's no mention of the sibling tool 'list_job_stages_for_job' for job-specific listing, nor any context about prerequisites or appropriate scenarios. 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.
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 date range filtering but fails to describe important behaviors: pagination mechanics (implied by parameters but not explained), whether this is a read-only operation, what permissions are required, rate limits, or what the output contains. For a list tool with 5 parameters, 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 that gets straight to the point with zero wasted words. It's appropriately sized for a list operation and front-loads the core functionality.
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 moderate complexity (5 parameters, no annotations, but with output schema), the description provides basic functionality but leaves significant gaps. The output schema existence means return values don't need explanation, but the description should better address parameter purposes and behavioral context. It's minimally adequate but incomplete for optimal 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?
Schema description coverage is 0%, so the schema provides only parameter names and types without descriptions. The description mentions 'optional created date range filters' which hints at the purpose of 'created_after' and 'created_before' parameters, but completely ignores the pagination parameters ('per_page', 'page', 'paginate') that constitute 3 of the 5 parameters. This partial coverage fails to compensate for the schema's lack of descriptions.
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 offers'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_offers_for_application' or 'get_offer' that might serve 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 mentions 'optional created date range filters' which provides some context about when filtering might be useful, but offers no guidance on when to use this tool versus alternatives like 'list_offers_for_application' or 'get_offer' from the sibling list. No explicit when/when-not instructions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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' implies a read-only operation, but the description doesn't mention pagination, sorting, filtering capabilities, or what authentication/rate limits might apply. For a listing tool with zero annotation coverage, this leaves significant behavioral gaps about how the operation actually works.
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 that gets straight to the point without unnecessary words. It's appropriately sized for a simple listing tool with no parameters. While it could be more informative, it's not verbose or poorly 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 that this is a simple listing tool with no parameters, an output schema exists, and no annotations are provided, the description is minimally adequate. However, it lacks context about what 'prospect post sections' are in this job board system, and with no annotations, it should ideally mention that this is a read-only operation. The existence of an output schema helps, but the description could provide more domain context.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for missing parameter documentation. A baseline of 4 is appropriate since there are no parameters to explain beyond what the schema already indicates.
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 prospect post sections on the job board' clearly states the action (list) and resource (prospect post sections), but it's somewhat vague about what 'prospect post sections' are and doesn't distinguish this tool from similar list_* siblings like list_job_posts or list_board_jobs. It provides basic purpose but lacks specificity about the domain context.
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 many sibling tools for listing various entities (e.g., list_job_posts, list_candidates), there's no indication of when prospect post sections are relevant or what distinguishes them from other listable resources. The description is purely functional without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List' implies a read operation, it doesn't address important behaviors like pagination handling (implied by parameters but not explained), caching behavior (hinted by 'force_refresh' parameter), authentication requirements, rate limits, or error conditions.
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 states the core purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information.
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?
For a read-only list tool with an output schema (which handles return values), the description covers the basic purpose adequately. However, with no annotations and 3 undocumented parameters, it leaves significant gaps in understanding tool behavior and usage. The existence of an output schema prevents this from being a complete failure.
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?
With 0% schema description coverage for 3 parameters, the description provides no information about parameters. It doesn't explain what 'per_page', 'page', or 'force_refresh' mean, their valid ranges, or how they affect the listing operation. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all rejection reasons') with a specific purpose ('for rejecting applications'). It distinguishes from other list tools by focusing on rejection reasons, but doesn't explicitly differentiate from similar list tools like 'list_close_reasons' or 'list_tags' in the sibling set.
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, timing considerations, or relationships to other tools like 'reject_application' or 'update_rejection_reason' that exist in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List all schools' but doesn't disclose behavioral traits like pagination behavior (implied by parameters), rate limits, authentication requirements, or what 'force_refresh' does. For a read operation with parameters, this leaves significant gaps in understanding 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 waste. It's front-loaded with the core purpose and appropriately sized for a simple listing tool, earning full marks for conciseness.
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 (a read operation), 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It states what the tool does but lacks details on parameters, usage context, and behavioral traits, though the output schema might cover return values. It's complete enough for basic understanding but has clear gaps.
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 for undocumented parameters. It adds no meaning beyond the schema—doesn't explain what 'per_page', 'page', or 'force_refresh' do, their typical values, or how they affect the listing. With 3 parameters and no param info in the description, it fails to compensate for the low 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 action ('List all schools') and the resource ('available for candidate education records'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'list_board_schools' or 'list_degrees' which might list similar educational entities, 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. With many sibling tools related to education and schools (e.g., 'list_board_schools', 'list_degrees'), there's no indication of context, prerequisites, or exclusions for this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 date range filtering but doesn't describe pagination behavior (implied by 'per_page' and 'page' parameters), rate limits, authentication requirements, or what happens when no filters are applied. For a list operation with 5 parameters, this is insufficient.
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 list operation and front-loads the core purpose.
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?
While an output schema exists (relieving the description from explaining return values), the tool has 5 parameters with 0% schema coverage and no annotations. The description only partially addresses the parameter gap and lacks behavioral context, making it minimally adequate but with clear gaps.
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 only mentions 'created date range filters' (covering 'created_after' and 'created_before'), leaving 3 parameters ('per_page', 'page', 'paginate') completely undocumented. The description adds minimal value beyond what parameter names suggest.
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 interview scorecards'), providing a specific purpose. However, it doesn't distinguish this tool from potential sibling tools like 'list_scorecards_for_application' or 'get_scorecard', which might handle more specific retrieval scenarios.
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 mentions 'optional created date range filters' but provides no guidance on when to use this tool versus alternatives like 'list_scorecards_for_application' or 'get_scorecard'. There's no mention of prerequisites, exclusions, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 doesn't disclose whether this is a read-only operation, how pagination works (despite parameters for it), what 'force_refresh' entails, or any rate limits or permissions required. The description 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 no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation, though this conciseness comes at the cost of detail.
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 (a list operation), the presence of an output schema reduces the need to describe return values. However, with no annotations, 0% schema coverage, and three parameters, the description is too sparse. It covers the basic purpose but lacks critical details about behavior and parameters, making it minimally adequate but with clear gaps.
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 but doesn't mention any parameters. The three parameters (per_page, page, force_refresh) are undocumented in both schema and description, leaving their purpose and usage unclear. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all candidate tags in the organization'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_tags_on_candidate' or 'create_tag', which would be needed for 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 'list_tags_on_candidate' or 'create_tag'. It lacks any context about prerequisites, typical use cases, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'submit via the Ingestion API,' which hints at an external API call but doesn't detail authentication needs, rate limits, side effects (e.g., data creation), or error handling. The description is minimal and lacks critical behavioral 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 a single, efficient sentence with no wasted words, clearly front-loading the core action. It's appropriately sized for the tool's complexity, though it could benefit from additional context without sacrificing 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 tool has 8 parameters with 0% schema coverage, no annotations, and an output schema exists (though not detailed here), the description is incomplete. It doesn't explain parameter meanings, behavioral traits, or usage context, making it inadequate for an agent to effectively invoke this tool without external knowledge.
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 0%, so the schema provides no parameter descriptions. The tool description does not mention any parameters, failing to compensate for the coverage gap. However, with 8 parameters including 3 required ones, the baseline is lowered due to lack of semantic guidance, but the description doesn't add value beyond the schema's structure.
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 ('submit') and the resource ('a candidate or prospect'), specifying it's done via the Ingestion API. It distinguishes from siblings like 'create_candidate' or 'add_prospect' by mentioning the Ingestion API, though it doesn't explicitly contrast with them. The purpose is specific but could be more distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'create_candidate' or 'add_prospect' is provided. The mention of 'Ingestion API' implies a specific context, but it doesn't clarify prerequisites, exclusions, or comparative scenarios. Usage is implied rather than stated, leaving gaps for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. While 'Remove' implies a destructive operation, it doesn't specify whether this is permanent or reversible, what permissions are required, or what happens to associated data. For a mutation tool with zero annotation coverage, this represents significant gaps in behavioral understanding.
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 gets straight to the point with no wasted words. It's appropriately sized for a simple deletion operation and front-loads the essential information.
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 that this is a destructive operation with no annotations, 0% parameter documentation, but with an output schema (which reduces need to describe return values), the description provides minimal but adequate coverage. It identifies the core action but lacks important context about parameters, permissions, and behavioral consequences that would be needed for safe operation.
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?
With 0% schema description coverage for both parameters, the description provides no additional information about what 'candidate_id' and 'education_id' represent or how to obtain them. The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving both parameters semantically undefined.
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 ('Remove') and target resource ('an education record from a candidate'), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'remove_employment' or other deletion tools, which would require specifying what distinguishes education removal from other removal operations.
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 'delete_candidate' or 'remove_employment', nor does it mention prerequisites such as needing existing education records or appropriate permissions. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 performs a removal/deletion, implying a destructive mutation, but doesn't mention whether the action is reversible, requires specific permissions, has side effects, or what the output contains. This leaves significant gaps for a mutation 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 a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
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 complexity (a destructive mutation with 2 parameters), no annotations, and an output schema (which helps), the description is incomplete. It covers the basic purpose but lacks behavioral details, parameter explanations, and usage context, though the output schema mitigates some gaps.
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 schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'candidate' and 'employment history record' but doesn't explain what 'candidate_id' and 'employment_id' represent, their formats, or how to obtain them. It adds minimal value beyond the parameter names.
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 ('Remove') and the resource ('an employment history record from a candidate'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'remove_education' or 'delete_candidate' beyond the resource name, which slightly limits 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?
The description provides no guidance on when to use this tool versus alternatives, such as 'update_candidate' or 'anonymize_candidate' for related operations. It lacks context about prerequisites, permissions, or typical workflows, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is destructive, requires specific permissions, has side effects (e.g., affecting user access), rate limits, or what the output contains, leaving significant gaps for a mutation 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 a single, efficient sentence with no wasted words, front-loading the key action and target. It's appropriately sized for the tool's apparent simplicity.
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, 0% schema coverage, and an output schema (which helps but isn't described), the description is inadequate. It lacks behavioral context, parameter explanations, and usage guidelines, failing to provide a complete picture for safe and 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 0%, but the description adds minimal semantics by implying 'permission ID' relates to 'future job permission'. However, it doesn't explain what 'user_id' or 'future_job_permission_id' represent, their formats, or how to obtain them, so it only partially compensates for the low 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 action ('Revoke') and target ('user's future job permission by permission ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'remove_job_permission' or 'list_future_job_permissions', which would require mentioning scope or type 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing permission IDs from 'list_future_job_permissions'), exclusions, or comparisons to similar tools like 'remove_job_permission', 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.
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 whether this operation requires specific permissions, is reversible, affects other data, or has rate limits. For a mutation tool, 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 no wasted words. It's appropriately sized for a simple operation and front-loads the core action 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?
The description covers the basic purpose adequately, and an output schema exists (which handles return values). However, for a mutation tool with no annotations and 0% schema coverage, it should provide more context about parameters, side effects, and usage scenarios to be truly complete.
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 schema provides no parameter descriptions. The tool description doesn't mention parameters at all, failing to explain what 'candidate_id' and 'tag_id' represent or where to obtain them. This leaves both parameters completely undocumented.
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 ('Remove') and target ('a tag from a candidate'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_tag_to_candidate' or 'list_tags_on_candidate' beyond the basic verb difference, 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 'delete_tag' (which might remove the tag entirely) or 'update_candidate' (which might handle tag modifications differently). It also doesn't mention prerequisites such as needing existing candidate and tag IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the Ingestion API but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, what format the data returns in, or if there are rate limits. The description is too minimal to provide adequate 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.
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 front-loaded with the core action and resource. However, it could be more informative while remaining concise, as it currently under-specifies the tool's purpose.
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 that the tool has no parameters and an output schema exists, the description doesn't need to explain inputs or return values. However, for a tool with no annotations and many sibling tools, the description is too minimal—it doesn't clarify what 'prospect pools' are or how this tool fits into the broader system, leaving 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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters, earning a baseline score of 4 for this context.
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 action ('Retrieve') and resource ('prospect pools'), but lacks specificity about what prospect pools are or what data they contain. It mentions 'via Ingestion API' which adds some context but doesn't differentiate from sibling tools like 'retrieve_ingestion_candidates' or 'retrieve_ingestion_jobs' that also use the Ingestion API.
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 about when to use this tool versus alternatives. With many sibling tools related to prospects and candidates (e.g., 'add_prospect', 'convert_prospect', 'list_candidates'), the description doesn't indicate whether this is for bulk retrieval, specific filtering, or other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions authentication requirements ('Requires API key for auth'), which is useful. However, it lacks details on behavioral traits such as whether this is a write operation (implied by 'submit'), potential side effects, rate limits, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is insufficient.
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 just two sentences, front-loading the main action ('Submit an application') and adding a critical constraint ('Requires API key for auth'). There is no wasted text, making it efficient 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 complexity (8 parameters, 4 required, mutation tool) and the presence of an output schema (which may cover return values), the description is incomplete. It lacks parameter explanations, detailed behavioral context, and usage differentiation from siblings. However, it does cover authentication and the core action, providing a minimal but not fully adequate foundation.
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%, meaning none of the 8 parameters have descriptions in the schema. The tool description does not mention any parameters, their meanings, or how they relate to submitting an application (e.g., job_id for targeting, personal details, optional attachments). It fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
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 ('submit') and resource ('application through the job board'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'create_application' or 'post_candidate', which appear to have similar functions, 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 minimal guidance by mentioning 'Requires API key for auth,' but it doesn't specify when to use this tool versus alternatives like 'create_application' or 'post_candidate' from the sibling list. No explicit when/when-not or alternative recommendations are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is an update operation (implying mutation) but doesn't mention permission requirements, whether changes are reversible, rate limits, or what the response contains. For a mutation 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 that front-loads the core purpose. Every word earns its place—no redundancy or fluff. It's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), no annotations, and moderate complexity with 3 parameters, the description is minimally adequate. It states the purpose but lacks usage context, detailed parameter guidance, and behavioral transparency. It meets a baseline but has clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'application_id' implicitly via 'on an application' and lists 'starts_at' and 'custom_fields' as updatable fields, providing some semantic context. However, it doesn't explain parameter formats (e.g., date format for starts_at, structure of custom_fields), leaving key details undocumented.
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 ('Update') and target resource ('current offer on an application'), specifying what fields can be updated ('new start date or custom fields'). It distinguishes from siblings like 'update_application' by focusing specifically on offers, though it doesn't explicitly contrast with 'get_current_offer' or 'list_offers_for_application'.
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 'update_application' or 'create_application'. The description mentions updating 'current offer' but doesn't clarify prerequisites (e.g., whether an offer must exist) or context for when this operation is appropriate versus creating a new offer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Update' implying a mutation, but doesn't specify required permissions, whether changes are reversible, or what the response looks like (though an output schema exists). 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 a single, efficient sentence with zero waste, front-loading the key action and resource. Every word earns its place, making it appropriately sized 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 moderate complexity (3 parameters, mutation operation) and the presence of an output schema (which reduces need to explain return values), the description is partially complete. However, with no annotations and low schema coverage, it lacks crucial behavioral and parameter details, making it adequate but with clear gaps.
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 mentions 'name or privacy setting', which maps to two of the three parameters (name, private), but doesn't explain the custom_field_id parameter or provide details like format constraints or the nullable nature of name and private. The description adds some value but doesn't fully compensate for the coverage gap.
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 ('Update') and the resource ('a custom field's name or privacy setting'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'update_custom_field_options' or 'update_candidate', which might also involve updates to related entities.
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 'create_custom_field' or 'delete_custom_field', nor does it mention prerequisites such as needing the custom_field_id. It lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is an update operation (implying mutation), but doesn't mention permission requirements, whether changes are reversible, error conditions, or what the output contains. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it 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 that states the core functionality without unnecessary words. It's appropriately sized for a simple update operation and front-loads the essential information.
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?
The description covers the basic purpose but lacks behavioral context (no annotations) and parameter details (0% schema coverage). However, the presence of an output schema means the description doesn't need to explain return values. For a 3-parameter mutation tool with output schema but no annotations, this is minimally adequate but has clear gaps.
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 schema provides only basic type information. The description mentions 'name or parent department' which maps to two of the three parameters, but doesn't explain department_id (the required parameter) or clarify that name and parent_id are optional/nullable. It adds some meaning but doesn't fully compensate for the schema's lack of descriptions.
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 ('Update') and resource ('a department's name or parent department'), making the purpose immediately understandable. However, it doesn't distinguish this tool from other update tools in the sibling list (like update_application, update_candidate, etc.), which would require mentioning what makes department updates unique.
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 create_department first), exclusions, or how it differs from similar update operations in the sibling tools. The agent must 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.
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's an update operation. It doesn't disclose behavioral traits like whether this requires admin permissions, if changes are reversible, what happens to associated data, rate limits, or what the output contains. 'Update' implies mutation but lacks critical 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 unnecessary words. It's appropriately sized for a simple update operation and front-loaded with the essential information.
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?
For a mutation tool with no annotations, 0% schema coverage, but with an output schema present, the description is moderately complete. It states what the tool does but lacks important context about permissions, valid status values, and behavioral implications. The output schema reduces the need to describe return values, but other gaps remain.
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 parameters are undocumented in the schema. The description mentions 'job post' and 'status' but doesn't explain what valid status values are (beyond 'live or offline' examples), format requirements, or how job_post_id should be obtained. It adds minimal meaning beyond parameter names.
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 ('Update') and resource ('a job post's publish status'), with specific examples ('e.g. live or offline'). It distinguishes itself from general update tools like 'update_job_post' by focusing on status changes, but doesn't explicitly differentiate from all sibling 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 is provided about when to use this tool versus alternatives. There's no mention of prerequisites, permissions needed, or comparison to related tools like 'update_job_post' or status-related operations in other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states this is an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error conditions, or what the output contains. 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 waste—it 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.
Completeness3/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), lack of annotations, and 0% schema coverage, the description is incomplete—it doesn't cover behavioral aspects, parameter details, or usage context. However, an output schema exists, which may provide return value information, partially mitigating the need for description completeness. This results in a baseline adequacy score.
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 schema provides no parameter descriptions. The description mentions 'rejection reason' and 'application,' which loosely map to the two parameters, but adds minimal semantic detail—it doesn't explain what 'rejection_reason_id' represents, valid values, or how to obtain them. With low coverage, the description fails to adequately compensate.
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 ('Update') and target ('rejection reason on an already-rejected application'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar sibling tools like 'reject_application' or 'update_application', which could also involve rejection reasons.
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 mentions 'already-rejected application,' which provides some context about when to use it (after rejection), but offers no guidance on when NOT to use it, prerequisites, or alternatives. It doesn't compare with sibling tools like 'reject_application' (which might set initial rejection) or 'update_application' (which might have broader functionality).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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' implies a mutation operation, but the description doesn't specify permissions required, whether changes are reversible, what happens when only first_name or last_name is provided, or any rate limits/constraints. This leaves significant gaps for a mutation 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple update operation and is perfectly front-loaded.
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?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, but with an output schema present, the description is minimally adequate. The output schema reduces the need to describe return values, but the description still lacks crucial behavioral context and parameter details that would make it complete.
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 schema provides no parameter descriptions. The description mentions 'first or last name' which partially covers two of the three parameters, but doesn't explain user_id (the required parameter) or the nullable nature of first_name/last_name. It adds some meaning but doesn't fully compensate for the coverage gap.
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 ('Update') and resource ('a user's first or last name'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_candidate' or 'update_application', which would be needed for 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 user_id), when not to use it, or how it differs from other update tools in the sibling list like 'update_candidate' or 'enable_user'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a read operation ('Get'), which implies it's likely non-destructive, but doesn't confirm safety, permissions required, rate limits, or error handling. The description is too sparse to adequately inform an agent about behavioral traits beyond the basic action.
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, direct sentence that front-loads the core action. There is no wasted language, making it efficient for quick understanding, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, read operation) and the presence of an output schema, the description is minimally adequate. However, with no annotations and sparse detail, it lacks context on permissions, error cases, and differentiation from siblings, leaving room for improvement in guiding an agent effectively.
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 description adds minimal but essential context: it specifies that the single parameter 'offer_id' is used to retrieve an offer by ID. With 0% schema description coverage and only one parameter, this compensates adequately by clarifying the parameter's role, though it doesn't detail format or constraints. The baseline is high due to low parameter count.
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 basic action ('Get a single offer') and resource ('by ID'), which is clear but minimal. It doesn't differentiate from sibling tools like 'list_offers' or 'get_current_offer', leaving the scope ambiguous. The purpose is understandable but lacks specificity about what an 'offer' entails in this context.
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 such as 'list_offers' for multiple offers or 'get_current_offer' for a specific type. The description implies usage for retrieving a single offer by ID but offers no context on prerequisites, error conditions, 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.
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 indicates a write operation ('Attach') but lacks details on permissions, side effects, error handling, or response format. The mention of base64 or URL input adds some context, but critical behavioral traits like mutation impact or rate limits are missing.
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 action and key details. It avoids redundancy and wastes no words, making it easy to parse quickly. The structure is optimal for its content.
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 6 parameters with 0% schema coverage and no annotations, the description partially compensates by explaining input methods and file types. An output schema exists, so return values need not be described. However, as a mutation tool with significant parameter complexity, the description lacks completeness in behavioral and usage aspects, making it minimally adequate.
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 0%, so the description must compensate. It adds meaning by explaining that 'content' and 'url' are alternative input methods for file attachment, and 'type' relates to file categories like 'resume, cover letter, etc.'. However, it doesn't clarify other parameters like 'candidate_id' or 'content_type', leaving gaps in 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 action ('Attach a file') and the target ('to a candidate'), with examples of file types ('resume, cover letter, etc.') and input methods ('via base64 content or URL'). It distinguishes from siblings like 'add_attachment_to_application' by specifying attachment to a candidate rather than an application, though it doesn't explicitly contrast them. The purpose is specific but could be more differentiated.
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 'add_attachment_to_application' or 'download_attachment'. It mentions input methods but not contextual prerequisites, such as candidate existence or permissions required. Usage is implied through parameter context 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.
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 implies a write operation ('Add') but doesn't disclose behavioral traits such as required permissions, whether the action is idempotent, error handling, or what happens on success/failure. This is inadequate for a mutation 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 with no wasted words, front-loading the core action. It's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the purpose but lacks usage guidelines, behavioral details, and parameter explanations. The output schema may help, but the description doesn't reference it, leaving gaps 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 0%, so the description must compensate. It lists parameters (school, discipline, degree, dates) but doesn't explain their semantics beyond naming them, and it omits 'candidate_id' and the nullable nature of some fields. The description adds minimal value over the schema, which documents parameters but without descriptions.
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 ('Add') and resource ('education record to a candidate'), specifying what the tool does. It distinguishes from siblings like 'add_employment' by focusing on education, though it doesn't explicitly contrast with them.
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 'update_candidate' or 'create_candidate', nor does it mention prerequisites or context for adding education records. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 lacks behavioral details. It mentions the optional verification send, but doesn't disclose permissions required, whether the operation is idempotent, rate limits, error conditions, or what happens if the email already exists. For a mutation tool with zero annotation coverage, this is insufficient.
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 and includes the optional behavior. Every word earns its place with no redundancy or fluff, making it easy 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 has an output schema (which reduces need to describe returns) but no annotations and 0% schema coverage, the description is moderately complete. It covers the basic action and optional verification, but lacks details on permissions, side effects, and parameter nuances, which are important for a mutation tool in a user management 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 0%, so the schema provides no parameter descriptions. The description adds minimal semantics by implying 'user_id' identifies the user and 'email' is the address to add, and notes the optional 'send_verification' behavior. However, it doesn't explain parameter formats (e.g., email validation) or constraints, leaving gaps for the 3 parameters.
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 ('Add an additional email address') and the target resource ('to a Greenhouse user'), with a specific optional behavior ('optionally sending verification'). It distinguishes from siblings like 'create_user' or 'update_user' by focusing on email addition, though it doesn't explicitly contrast with similar 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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user must exist), exclusions, or compare with other email-related tools (e.g., 'add_email_note_to_candidate'), leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 lacks behavioral details. It implies a write operation ('Add') but doesn't disclose permissions needed, whether it's idempotent, error handling, or what the output contains (though an output schema exists). This is inadequate for a mutation 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 a single, efficient sentence that front-loads the core purpose and lists optional parameters without waste. Every word contributes directly to understanding the tool's function.
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?
For a mutation tool with no annotations, 0% schema coverage, but an output schema, the description is minimally adequate. It covers the purpose and parameters at a high level but lacks behavioral context and usage guidance, relying on the output schema for return values.
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 0%, but the description adds value by listing optional fields (company, title, dates) beyond the required candidate_id. However, it doesn't explain parameter formats (e.g., date strings) or constraints, leaving gaps compensated only by the schema's structure.
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 ('Add') and resource ('employment history record to a candidate'), specifying what the tool does. It distinguishes from siblings like 'add_education' by focusing on employment, though it doesn't explicitly contrast with similar tools like 'remove_employment'.
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 (e.g., 'update_candidate' or 'remove_employment'), nor does it mention prerequisites like candidate existence. It only states the basic function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool grants permissions (a write operation) but doesn't disclose behavioral aspects like required permissions, whether changes are reversible, rate limits, or what happens if the user already has the permission. The description is minimal and lacks crucial operational 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, well-structured sentence that efficiently conveys the core purpose and optional scope. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (permission mutation with 4 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It covers the basic purpose but lacks parameter explanations, behavioral context, and usage guidelines needed for safe operation.
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 mentions optional scoping to 'office or department', which hints at two parameters, but doesn't explain the four parameters (user_id, user_role_id, office_id, department_id) or their relationships. No details on what user_role_id represents or how scoping works are provided.
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 ('Grant'), target resource ('a user a role on all future jobs'), and optional scope ('optionally scoped to an office or department'). It distinguishes from sibling 'add_job_permission' by specifying 'future jobs', but doesn't explicitly contrast with 'remove_future_job_permission' or other permission tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for granting permissions on future jobs, but doesn't explicitly state when to use this vs. 'add_job_permission' (which likely applies to existing jobs) or 'change_user_permission_level'. No prerequisites, exclusions, or alternative scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a write operation ('Add') but doesn't disclose behavioral aspects like required permissions, whether notes are editable/deletable, rate limits, or what the response contains. The visibility feature is mentioned but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste - every word contributes to understanding the tool's purpose and parameters. Front-loaded with the core action and target.
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 a write operation with 3 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers what the tool does at a high level but lacks behavioral context, usage guidance, and parameter details that would be helpful 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'candidate' (mapping to candidate_id), 'text note' (mapping to body), and 'optional visibility' (mapping to visibility), covering all three parameters at a high level. However, it doesn't provide format details, constraints, or examples beyond what's implied.
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 ('Add a text note') and target ('to a candidate's activity feed'), with an additional feature ('with optional visibility'). It distinguishes from obvious siblings like 'add_email_note_to_candidate' by specifying text notes, but doesn't explicitly differentiate from all other note/activity-related 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 'add_email_note_to_candidate' or 'get_activity_feed'. The description mentions optional visibility but doesn't explain when to choose private vs public, or any prerequisites for using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the creation action but fails to address critical aspects such as required permissions, whether the operation is idempotent, what happens on conflicts, or the expected response format. 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, efficient sentence that directly states the tool's purpose and key parameters without any fluff or redundancy. It is 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.
Completeness3/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 creation operation with 5 parameters), no annotations, and an output schema (which reduces the need to describe return values), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage guidelines, and full parameter semantics, leaving room for improvement in completeness.
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 lists three parameters (name, field_type, value_type), which correspond to the required parameters in the schema. However, with 0% schema description coverage and two additional optional parameters (private, generate_email_token) not mentioned, it provides only partial semantic context. The baseline is 3 because it adds some meaning but doesn't fully compensate for the schema's lack of descriptions.
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 a new custom field') and specifies the key attributes involved ('with name, field_type, and value_type'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'create_custom_field_options' or other field-related tools, which would be needed for 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_custom_field' or 'create_custom_field_options', nor does it mention prerequisites or contextual constraints. It merely states what the tool does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a creation operation but doesn't mention permission requirements, whether the opening becomes active immediately, what happens if duplicate opening IDs are used, or what the response contains. For a write operation with zero annotation coverage, this is insufficient.
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 states the core purpose upfront and mentions key optional parameters. Every word serves a purpose with no wasted text, making it appropriately concise for a tool description.
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 this is a write operation with 5 parameters (0% schema coverage) and no annotations, the description is minimally adequate but has significant gaps. The existence of an output schema reduces the need to describe return values, but more context about behavior, parameter usage, and alternatives would be helpful for a creation tool.
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 0%, so the description must compensate. It mentions three optional parameters (opening ID, status, custom fields) but omits 'close_reason_id' and doesn't explain what values are valid for 'status' or the structure of 'custom_fields'. The description adds some meaning but doesn't fully compensate for the schema coverage gap.
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 a new opening') and resource ('on a job'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'create_job' or 'update_job_opening', but the focus on 'opening' provides some distinction within the job management context.
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 about when to use this tool versus alternatives like 'create_job' (for creating the job itself) or 'update_job_opening' (for modifying existing openings). The description mentions optional parameters but doesn't explain when they should be used or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 creates a new office, implying a write operation, but doesn't mention any behavioral traits like whether it requires specific permissions, if the creation is idempotent, what happens on duplicate names, or what the response includes. This leaves significant gaps for a mutation 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 a single, efficient sentence that front-loads the core action ('Create a new office') and briefly lists parameters. There is no wasted verbiage or redundancy, making it easy 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 complexity (a mutation with 3 parameters), lack of annotations, and 0% schema description coverage, the description is incomplete. It doesn't address behavioral aspects like permissions or idempotency, and while an output schema exists (which relieves the need to explain return values), the parameter semantics are under-specified. The description is minimally adequate 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?
The description adds minimal semantic context: it mentions 'name' and 'optional parent office and location,' which aligns with the three parameters in the schema. However, with 0% schema description coverage, the schema provides no details about parameter formats or constraints. The description doesn't compensate by explaining parameter purposes beyond their names, leaving the agent to guess at semantics like what 'parent_id' refers to or 'location' format.
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 a new office') and specifies the resource ('office'), making the purpose immediately understandable. It distinguishes from siblings like 'update_office' or 'list_offices' by focusing on creation. However, it doesn't explicitly differentiate from other creation tools like 'create_department' or 'create_job' beyond the resource type.
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., permissions needed), when not to use it, or how it relates to sibling tools like 'list_offices' for verification or 'update_office' for modifications. 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.
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 this is a creation operation but doesn't mention permissions required, whether tags are unique, if there are rate limits, or what the output looks like. For a mutation tool with zero annotation coverage, this is insufficient.
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 with the core action.
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 has an output schema (which reduces the need to describe return values) but no annotations and low schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and parameter nuances that would be helpful for an AI 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 description mentions the parameter 'name' ('with the given name'), which aligns with the single parameter in the schema. However, with 0% schema description coverage, the description adds minimal value beyond what's implied by the parameter name itself. It doesn't explain constraints like length or format.
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 candidate tag') with the specific input ('with the given name'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'add_tag_to_candidate' or 'bulk_tag', which would require a 5.
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 'add_tag_to_candidate' or 'bulk_tag', nor does it mention prerequisites or context. It simply states what the tool does without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 performs a deletion, implying it's destructive, but doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., cascading deletions), or returns confirmation data. For a destructive operation, this lack of detail 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, clear sentence with no wasted words. It's front-loaded with the key action ('Delete') and resource, making it efficient and easy to parse.
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 that this is a destructive tool with no annotations, 0% schema description coverage, but an output schema exists (which should cover return values), the description is minimally adequate. It states the purpose but lacks critical behavioral details (e.g., permissions, irreversibility) and usage context. The output schema mitigates some gaps, but overall completeness is limited.
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 'a specific opening from a job', which implies the need for identifiers (job_id and opening_id), aligning with the two required parameters in the schema. However, with 0% schema description coverage, the description doesn't add details beyond this implication—it doesn't explain what these IDs represent, their format, or where to find them. The baseline is 3 since the schema defines the parameters, but the description doesn't fully compensate for the coverage gap.
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 specific opening from a job'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_application' or 'delete_candidate', which would require more specific context about what a 'job opening' entails in this system.
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., whether the opening must be in a certain state), consequences (e.g., if deletion affects related applications), or when to choose other deletion tools like 'delete_application' or 'delete_candidate' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the behavioral effect (prevents login) but omits critical details: whether this is reversible (via 'enable_user'), permission requirements, rate limits, or what the output contains. For a destructive tool, 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 front-loads the core action and effect, 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.
Completeness3/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 user operation), lack of annotations, and presence of an output schema, the description is moderately complete. It states the purpose and effect but misses behavioral context like reversibility and permissions. The output schema may cover return values, reducing the burden, but key operational details are omitted.
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 0%, but the description adds no parameter information beyond what the schema implies (a user_id is needed). It doesn't explain what 'user_id' represents, format, or where to find it. With 1 parameter and no schema descriptions, the baseline is 3 as it minimally acknowledges the need for a user identifier.
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 ('Disable') and resource ('a Greenhouse user'), and specifies the effect ('preventing them from logging in'). It distinguishes from siblings like 'enable_user' by indicating opposite functionality, though it doesn't explicitly compare to all sibling 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?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'delete_user', 'update_user'), prerequisites (e.g., permissions needed), or consequences beyond login prevention. It mentions the effect but lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 lacks behavioral details. It doesn't disclose permission requirements, whether the operation is reversible, what happens to user data, or any rate limits. 'Re-enable' implies a state change but offers no further 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 with zero wasted words. It's front-loaded and gets straight to the point without unnecessary elaboration.
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?
For a mutation tool with no annotations, 0% schema coverage, but with an output schema present, the description is minimally adequate. It states the core action but lacks important context about permissions, side effects, and parameter meaning that would be needed for safe 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 0%, but the description doesn't add any parameter information beyond what's implied by the tool name. The single parameter 'user_id' is undocumented in both schema and description. Baseline 3 applies as schema coverage is low but description doesn't compensate.
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 ('Re-enable') and target ('previously disabled Greenhouse user'), providing specific verb+resource. It doesn't explicitly differentiate from sibling 'disable_user', but the purpose is unambiguous.
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_user' or 'create_user', nor does it mention prerequisites (e.g., user must be disabled). It only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool retrieves activity data but doesn't disclose behavioral traits such as whether it's read-only (implied by 'Get'), authentication requirements, rate limits, pagination, error handling, or the format/scope of returned data. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core purpose ('Get the activity feed') and specifies the resource and included activity types. There is no wasted verbiage or redundancy, 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 low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema description coverage, it should provide more behavioral context (e.g., read-only nature, data format hints) to compensate. It meets basic needs but lacks depth for full 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?
Schema description coverage is 0%, but the description adds context by specifying that the 'candidate_id' parameter is used to fetch the activity feed for that candidate. However, it doesn't explain the parameter's format, constraints, or how it relates to other tools (e.g., if it must match an existing candidate). With one parameter and no schema descriptions, the description provides basic meaning but lacks depth.
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 ('activity feed for a candidate'), specifying the types of activities included (notes, emails, stage changes). It distinguishes from siblings like 'get_candidate' or 'list_candidates' by focusing on activity data rather than candidate details. However, it doesn't explicitly differentiate from potential activity-related tools like 'list_interviews_for_application', though none are present in the sibling list.
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 candidate ID), exclusions, or comparisons to other tools that might retrieve candidate data (e.g., 'get_candidate' for basic info). Usage is implied only by the tool name and parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a 'Get' operation, implying read-only access, but doesn't clarify permissions, rate limits, error handling, or what the output contains. The description adds minimal context beyond the basic action.
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 no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
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 has an output schema (which handles return values) and a simple parameter structure, the description is minimally adequate. However, with no annotations and low schema coverage, it lacks details on behavior, usage context, and error cases, making it incomplete for safe and effective use by an AI 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 1 parameter with 0% description coverage, and the description mentions 'by ID', which aligns with the 'answer_option_id' parameter. However, it doesn't provide additional semantics like ID format, valid ranges, or examples. The description compensates slightly but leaves gaps in 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 action ('Get') and the resource ('a single demographic answer option by ID'), making the purpose understandable. It distinguishes itself from siblings like 'list_answer_options' by specifying retrieval of a single item rather than a list. However, it doesn't fully explain what a 'demographic answer option' is in this context.
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 answer option ID), compare it to sibling tools like 'list_answer_options' or 'get_answer', or specify error conditions (e.g., what happens if the ID doesn't exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 data ('Get'), implying a read-only operation, but does not specify permissions, rate limits, error handling, or response format. 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 no wasted words: 'Get a single application by ID.' It is front-loaded and directly conveys the core functionality, 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 (one parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and low schema coverage, it lacks details on behavior, usage context, and parameter specifics. It meets basic requirements but has clear gaps in completeness.
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 one parameter ('application_id') with 0% description coverage. The description adds minimal semantics by implying the parameter is used to identify the application, but does not elaborate on format, constraints, or examples. With low schema coverage, the description only partially compensates, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a single application by ID.' It specifies the verb ('Get'), resource ('application'), and scope ('single' by 'ID'). However, it does not differentiate from siblings like 'get_candidate' or 'list_applications', which is why it scores 4 instead of 5.
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 does not mention sibling tools like 'list_applications' for multiple applications or 'get_candidate' for related data, nor does it specify prerequisites or exclusions. This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'Get' implies a read operation, the description doesn't specify whether this requires authentication, what happens if the department doesn't exist, rate limits, or the format of returned data. For a tool with no 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, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential information without unnecessary elaboration.
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 (single parameter, read operation) and the existence of an output schema, the description is reasonably complete for basic understanding. However, with no annotations and 0% schema description coverage, it lacks important behavioral context that would be needed for robust agent usage.
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 mention any parameters, while the schema has one required parameter (department_id) with 0% description coverage. Since schema_description_coverage is 0%, the description should compensate but doesn't. The baseline would be lower, but the tool has only one parameter and an output schema exists, making this minimally adequate.
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 department from the job board'), making the purpose immediately understandable. It distinguishes this from list operations like 'list_board_departments' by specifying 'a single department', though it doesn't explicitly contrast with other department-related tools like 'get_department' or 'create_department'.
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 this over 'list_board_departments' for multiple departments, 'get_department' (a sibling tool with similar name), or other department-related operations. There's no context about prerequisites 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.
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 this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, error conditions, or what 'published' means in this context. For a tool with no annotation coverage, this leaves significant gaps in understanding how it 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 that states the core purpose and key feature ('optional application questions') without any wasted 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values) but no annotations and low parameter documentation, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and parameter meanings, leaving room for improvement in completeness for effective tool selection.
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 application questions,' which correlates with the 'questions' boolean parameter in the schema, adding some semantic context. However, with 0% schema description coverage, the 'job_id' parameter remains undocumented in both schema and description. The description provides marginal value but doesn't fully compensate for the coverage gap, especially for the required 'job_id' parameter.
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 published job'), making the purpose understandable. It also mentions 'optional application questions' which adds specificity about what can be retrieved. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_job' or 'get_job_post', which might retrieve different aspects of job data.
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 many sibling tools like 'get_job', 'get_job_post', and 'list_board_jobs', there's no indication of what makes this tool unique or when it should be preferred. The mention of 'optional application questions' hints at a feature but doesn't clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a read operation ('Get'), which implies it's likely safe and non-destructive, but doesn't confirm this or describe any side effects, authentication requirements, rate limits, or error conditions. 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 that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. This is an excellent example of conciseness in tool descriptions.
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 that there's an output schema (which handles return values), no annotations, and a simple single-parameter input schema, the description is minimally adequate. It states what the tool does but lacks guidance on usage, parameter details, and behavioral context. For a retrieval tool in a complex system with many siblings, it should do more to help the agent navigate alternatives and understand nuances.
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 1 parameter with 0% description coverage, so the schema provides no semantic context. The description doesn't mention the 'office_id' parameter at all, failing to compensate for the schema's lack of documentation. However, since there's only one required parameter and its purpose is somewhat inferable from the tool name, the baseline score of 3 is appropriate—adequate but with clear 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 action ('Get') and resource ('a single office from the job board'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_office' or 'list_board_offices', which appears to be a similar retrieval operation for offices. The description is specific but lacks 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 like 'get_office' or 'list_board_offices'. It doesn't mention prerequisites, context, or exclusions. The agent must infer usage from the tool name and parameters alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 retrieving a single candidate by ID but doesn't cover critical aspects like authentication requirements, error handling (e.g., invalid ID), rate limits, or whether it's a read-only operation. This leaves significant gaps for a tool that likely interacts with sensitive candidate 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, efficient sentence with no wasted words. It's front-loaded with 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.
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 parameter) and the presence of an output schema (which likely defines the return structure), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks context on behavioral traits and usage scenarios, making it insufficient for optimal 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?
The input schema has 0% description coverage, but the description adds minimal value by specifying 'by ID', which clarifies the purpose of the 'candidate_id' parameter. However, it doesn't explain parameter constraints (e.g., ID format, valid ranges) or provide examples, so it only partially compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a single candidate by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_user' or 'get_application', which follow the same pattern, so it lacks 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?
No guidance is provided on when to use this tool versus alternatives such as 'list_candidates' or 'search_candidates_by_email'. The description only states what it does, not when it's appropriate, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the 'most recent' offer, implying a read-only operation, but doesn't clarify error handling (e.g., if no offers exist), permissions, or rate limits. 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 front-loads the core purpose without unnecessary words. It earns its place by clearly stating what the tool does, making it appropriately sized 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?
With an output schema present, the description doesn't need to explain return values, and it covers the basic purpose. However, for a tool with no annotations and low schema coverage, it lacks details on behavioral traits and usage context, making it minimally adequate but with 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?
The input schema has 1 parameter with 0% description coverage, but the description adds context by specifying 'application_id' is used to fetch the offer. However, it doesn't explain format constraints or validation rules. Given the low schema coverage, the description provides some compensation but not fully, aligning with the baseline.
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 target resource ('current offer for an application'), making the purpose understandable. However, it doesn't distinguish this tool from sibling 'get_offer' or 'list_offers_for_application', which appear to handle offers differently, so it misses full 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 like 'get_offer' or 'list_offers_for_application'. It lacks context about prerequisites, such as whether the application must have offers, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a read operation ('Get'), but doesn't mention authentication requirements, rate limits, error handling, or response format. While 'Get' implies non-destructive behavior, the description lacks details about what happens with invalid IDs, whether the operation is idempotent, or any side effects. For a retrieval tool with zero annotation coverage, this is insufficient.
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 functionality without unnecessary words. It's front-loaded with the essential information and contains zero redundant content. Every word earns its place in this minimal but complete statement of purpose.
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 that an output schema exists (which presumably documents the return structure), the description doesn't need to explain return values. However, for a retrieval tool with no annotations and minimal parameter documentation, the description should provide more context about authentication, error conditions, and typical usage patterns. The existence of an output schema raises the baseline, but the description remains too sparse for optimal agent 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?
Schema description coverage is 0%, but the description compensates by specifying that the single parameter is used 'by ID'. However, it doesn't explain what a custom field ID represents, its format, or where to obtain valid IDs. The description adds minimal value beyond what can be inferred from the parameter name 'custom_field_id' in the schema. With only one parameter, the baseline expectation is higher than for multi-parameter tools.
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 custom field by ID'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_custom_fields' or 'update_custom_field', but the singular vs plural distinction is implied. The description avoids tautology by specifying the 'by ID' aspect rather than just restating the tool 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 like 'list_custom_fields' or 'update_custom_field'. It doesn't mention prerequisites, error conditions, or typical use cases. The agent must infer usage from the tool name and description alone without explicit context about when this specific retrieval method is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it's a read operation ('Get'), implying non-destructive behavior, but doesn't cover aspects like error handling, authentication needs, rate limits, or response format. This leaves significant gaps for a 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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 low complexity (single parameter, read-only implied) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on behavioral traits and usage context, making it incomplete for optimal agent guidance despite the output schema support.
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 'by ID', which aligns with the single parameter 'department_id' in the input schema. However, with 0% schema description coverage, the schema provides no details about the parameter. The description adds basic meaning but doesn't elaborate on ID format, constraints, or examples, resulting in a baseline score due to incomplete compensation.
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 single department'), specifying it's retrieved by ID. However, it doesn't distinguish this from sibling tools like 'list_departments' or 'update_department', which would require explicit comparison for a score of 5.
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 'list_departments' for multiple departments or 'update_department' for modifications. The description lacks context about prerequisites or typical use cases, offering minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Get EEOC data' but doesn't disclose behavioral traits such as whether this is a read-only operation, what permissions are required, if it returns structured data or a file, error handling, or rate limits. For a data retrieval 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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
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 (1 parameter) and the presence of an output schema (which likely describes the EEOC data structure), the description is somewhat complete for basic understanding. However, with no annotations and 0% schema description coverage, it lacks crucial context like behavioral traits and parameter details, making it inadequate for fully informed use without external knowledge.
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 'for a specific application', which aligns with the 'application_id' parameter in the schema. However, schema description coverage is 0%, so the schema provides no details about the parameter. The description adds minimal semantic context (it's for an application) but doesn't explain what an 'application_id' is, its format, or where to obtain it, leaving the parameter poorly documented.
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 the resource ('EEOC data submitted for a specific application'), making the purpose understandable. It distinguishes from sibling tools like 'list_eeoc' (which likely lists EEOC data broadly) by specifying retrieval for a single application. However, it doesn't explicitly contrast with other data-fetching tools like 'get_application', leaving minor 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 application ID), exclusions (e.g., not for bulk EEOC data), or direct comparisons to siblings like 'list_eeoc' or 'get_application'. Usage is implied through the parameter 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.
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 this is a read operation ('Get'), which implies it's likely non-destructive, but doesn't mention authentication requirements, rate limits, error handling, or what happens if the ID doesn't exist. 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 states the core functionality without unnecessary words. It's perfectly front-loaded and wastes no space, 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 simple nature (single parameter lookup), the existence of an output schema reduces the need to describe return values. However, with no annotations and minimal parameter guidance, the description leaves gaps in behavioral context and usage scenarios that could help the agent 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 mentions the single parameter ('by ID'), which aligns with the input schema's 'email_template_id'. However, with 0% schema description coverage, the schema provides no additional parameter documentation. The description adds minimal semantic context (it's an ID lookup) but doesn't specify ID format, valid ranges, or where to obtain IDs, leaving significant 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 action ('Get') and resource ('a single email template by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_email_templates' or explain what distinguishes a 'get' from a 'list' operation, 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 'list_email_templates' or other get_* tools. There's no mention of prerequisites, error conditions, or typical use cases, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Get' implies a read operation, but it doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the job ID doesn't exist. For a read tool with zero annotation coverage, this leaves significant gaps in understanding how it 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 perfectly concise at 5 words, front-loading the essential information with zero wasted language. Every word ('Get', 'single', 'job', 'by', 'ID') contributes directly to understanding the tool's purpose.
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 has an output schema (which handles return values), a single parameter, and no annotations, the description is minimally adequate. It states what the tool does but lacks context about usage, behavior, and parameter details that would be helpful for an agent. For a simple read operation, this is the bare minimum.
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 'by ID' which aligns with the single 'job_id' parameter in the schema. However, with 0% schema description coverage, the schema provides no details about the parameter. The description adds minimal semantics (it's an ID) but doesn't explain format, constraints, or where to obtain valid IDs. This meets the baseline for a single parameter tool but doesn't fully compensate for the schema gap.
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 job by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_job_opening' or 'get_job_post', which might retrieve similar job-related data through different mechanisms or scopes.
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 many sibling tools like 'list_jobs' (for multiple jobs), 'get_job_opening', or 'get_job_post', there's no indication of when this specific single-job retrieval is appropriate versus other job-related get operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a read operation ('Get'), implying it's non-destructive, but doesn't cover other aspects like authentication requirements, rate limits, error handling, or what happens if the office ID doesn't exist. For a 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 that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving optimal conciseness for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter) and the presence of an output schema (which likely defines the return structure), the description is minimally adequate. However, with no annotations and low schema coverage, it lacks details on behavioral traits and parameter semantics. It meets the baseline for a basic read operation but doesn't provide comprehensive 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?
The input schema has 0% description coverage, but the description adds minimal value by implying the 'office_id' parameter is required to fetch a specific office. However, it doesn't explain the parameter's format, constraints, or where to obtain valid IDs. With low schema coverage, the description partially compensates but doesn't fully address the documentation gap.
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 office by ID'), making the purpose unambiguous. It distinguishes this as a retrieval operation for a specific office rather than listing offices, which aligns with the sibling tool 'list_offices'. However, it doesn't explicitly differentiate from other 'get_' tools like 'get_department' or 'get_user' beyond the resource 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 an office ID), compare it to 'list_offices' for browsing, or indicate any contextual constraints. Usage is implied only by the tool name and parameter, with no explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't specify error conditions (e.g., invalid ID), rate limits, authentication requirements, or what happens if the question set doesn't exist. For a 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 that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy 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 (one parameter) and the presence of an output schema (which likely describes the returned question set), the description is minimally adequate. However, with no annotations and low schema coverage, it lacks details on usage context, error handling, and behavioral traits, making it incomplete for safe and effective use by an AI 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 schema has 0% description coverage, with one required parameter 'question_set_id' of type integer. The description mentions 'by ID', which adds minimal context about the parameter's purpose but doesn't clarify format constraints (e.g., valid ID ranges) or where to obtain the ID. Since the schema lacks descriptions, the description provides some value but doesn't fully compensate for the coverage gap.
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 demographic question set by ID'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'list_question_sets', which appears to retrieve multiple question sets rather than a single one by ID.
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 'list_question_sets' or 'list_questions_for_question_set'. It also doesn't mention prerequisites, such as needing a valid question_set_id, or contextual factors like permissions or availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get' which implies a read operation, but doesn't specify permissions, rate limits, or response format. 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 no wasted words. It's front-loaded with the core action and resource, making it easy 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 that an output schema exists (which handles return values), the description's minimalism is somewhat acceptable. However, for a tool with no annotations and low schema description coverage, it should provide more context on behavior and usage to be fully complete.
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 0%, but the description adds minimal semantic context by mentioning 'by ID', which clarifies the purpose of the 'scorecard_id' parameter. However, it doesn't explain format constraints or provide examples, so it only partially compensates for the lack of schema descriptions.
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 interview scorecard by ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_scorecards' or 'list_scorecards_for_application', which would require a 5.
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 'list_scorecards' or 'list_scorecards_for_application'. The description only states what it does, not when it's appropriate, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'Get' implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens if the user ID doesn't exist. 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 that communicates the core functionality without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the essential information.
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 (single parameter, read operation) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and low schema coverage, it should provide more behavioral context about authentication, error handling, and differentiation from sibling tools.
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 'by ID' which aligns with the single 'user_id' parameter in the schema. However, with 0% schema description coverage, the schema provides no details about the parameter. The description adds minimal value by indicating the parameter type (ID) but doesn't specify format constraints, valid ranges, or where to find user IDs.
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 Greenhouse user by ID'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'list_users' or 'retrieve_current_user', which would require more specific context about when to use each.
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 about when to use this tool versus alternatives like 'list_users' (for multiple users) or 'retrieve_current_user' (for the current user). The description only states what it does, not when it's appropriate compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'List all' suggests a read-only operation, the description doesn't address important behavioral aspects like pagination, rate limits, authentication requirements, error conditions, or what happens when an invalid question_id is provided. For a tool with no annotation coverage, this represents a significant gap in behavioral 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 gets straight to the point with zero wasted words. It's appropriately sized for a simple list operation and front-loads the essential information about what the tool does.
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 that there's an output schema (which handles return values) and only one parameter, the description is minimally adequate. However, with no annotations and 0% schema description coverage, the description should do more to explain parameter constraints and behavioral expectations. It's complete enough for a basic list operation but leaves important questions unanswered about parameter validity and operational 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?
The schema has 0% description coverage, so the description needs to compensate. It mentions 'a specific demographic question' which provides context for the question_id parameter, but doesn't explain what format or range of values question_id accepts, where to find valid question_ids, or whether there are any constraints. The description adds some semantic meaning but doesn't fully compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all answer options') and the target resource ('for a specific demographic question'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_answer_options' or 'get_answer_option', which appear to be related but not identical operations.
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 sibling tools dealing with answers and answer options (list_answer_options, get_answer_option, list_answers, etc.), but the description offers no comparison or context about when this specific tool is appropriate versus those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 listing answers but lacks details on behavioral traits such as pagination, rate limits, authentication needs, or what happens if the application_id is invalid. This leaves gaps for an AI agent to understand operational constraints.
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 is 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.
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 (1 parameter) and the presence of an output schema, the description is somewhat complete but lacks behavioral context. Without annotations, it should ideally mention more about the operation's safety or limitations, though the output schema reduces the need to explain return values.
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 0%, but the description adds meaning by clarifying that 'application_id' is required to list answers for a specific application. However, it does not provide format details or constraints beyond what the schema's type and title imply, resulting in minimal compensation for the coverage gap.
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 ('List all') and resource ('demographic survey answers submitted for a specific application'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'list_answers' or 'list_answers_for_question', which could cause confusion about scope.
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 (e.g., 'list_answers' or 'list_answers_for_question'), nor does it mention prerequisites or exclusions. It only specifies the required parameter without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 whether this is a read-only operation, if it requires specific permissions, pagination behavior, rate limits, or what the output contains (though an output schema exists). For a tool with zero annotation coverage, this is insufficient.
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 no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly, though its 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.
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 (1 parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it should provide more context on usage and behavior to be fully helpful, especially in a server with many sibling tools.
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 implies a 'job_id' parameter by stating 'for a job', but with 0% schema description coverage, it doesn't add meaningful semantics beyond what the schema's title 'Job Id' provides. Since there's only one parameter, the baseline is higher, but the description doesn't compensate for the lack of schema details (e.g., format 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 'List all approval flows for a job' clearly states the action (list) and resource (approval flows) with a specific scope (for a job). It distinguishes from siblings like 'list_pending_approvals' by focusing on job-specific flows rather than general pending approvals, though it doesn't explicitly contrast with other list tools like 'list_approval_flow' (singular).
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 job_id), exclusions, or compare with similar tools like 'get_approval_flow' (singular) or 'list_pending_approvals', 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.
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. While 'List' implies a read-only operation, it doesn't specify whether this requires authentication, how results are paginated, what the output format is, or any rate limits. The description lacks critical behavioral context needed for safe and effective use.
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 listing tool 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?
For a simple read operation with one parameter and an output schema, the description provides the basic purpose but lacks important context. With no annotations and missing parameter documentation, it's incomplete for reliable use, though the presence of an output schema reduces the need to describe return values.
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 one parameter ('content') with 0% description coverage in the schema. The tool description doesn't mention this parameter at all, leaving its purpose and effect completely undocumented. However, with only one parameter and an output schema present, the baseline is 3 as the description doesn't add value but the minimal parameter count reduces severity.
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 ('List') and resource ('all published jobs on the board'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish itself from sibling tools like 'list_jobs' or 'list_job_posts', which appear to serve similar listing functions in the same domain.
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 'list_jobs' or 'list_job_posts', nor does it mention any prerequisites, exclusions, or contextual constraints. It simply states what the tool does without offering usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List all close reasons' which implies a read operation, but doesn't disclose behavioral traits like pagination behavior (though parameters suggest it), rate limits, authentication requirements, or what 'force_refresh' does. The description is minimal and lacks operational 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, clear sentence that efficiently states the tool's purpose. It's appropriately sized and front-loaded with no wasted words or unnecessary elaboration.
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 that there's an output schema (which handles return values), no annotations, and a simple read operation with well-documented parameters in the schema, the description is minimally adequate. However, it lacks context about when to use it and behavioral details, making it incomplete for optimal agent 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?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter information. The baseline is 3 because the schema fully documents the three parameters (per_page, page, force_refresh) with titles and defaults, though the description adds no semantic value beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('close reasons') with specific context ('used when closing job openings'). It distinguishes from other list tools by focusing on close reasons, but doesn't explicitly differentiate from similar list tools like 'list_rejection_reasons' among siblings.
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. The description doesn't mention prerequisites, when this tool is appropriate, or what other tools might be used for related purposes. It's a standalone statement without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 listing options but does not cover critical aspects such as whether this is a read-only operation, potential error conditions (e.g., invalid ID), pagination, or the format of returned data. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes to understanding the purpose.
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 (1 parameter) and the presence of an output schema (which should define return values), the description is minimally adequate. However, without annotations and with incomplete parameter documentation, it lacks details on behavioral traits and usage context, making it only partially complete for effective 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 input schema has 1 parameter with 0% description coverage, but the description adds meaningful context by specifying that the parameter is for a 'dropdown/multi-select custom field'. This clarifies the type of field involved, partially compensating for the schema gap. However, it does not detail the parameter's expected format or constraints beyond the implied ID usage.
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 options for a dropdown/multi-select custom field'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'list_custom_fields' or 'get_custom_field', which might list fields themselves rather than their options, leaving room for minor 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?
No guidance is provided on when to use this tool versus alternatives. For instance, it does not specify prerequisites (e.g., needing a valid custom_field_id) or compare to tools like 'get_custom_field' that might retrieve field details including options. The description lacks context for selection among related list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation by using 'List', but doesn't specify permissions required, pagination behavior, error handling, or what the output contains (though an output schema exists). 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, clear sentence with no wasted words. It's front-loaded with the core action and efficiently communicates the essential information without unnecessary elaboration.
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 parameter, read operation) and the presence of an output schema (which handles return values), the description is minimally complete. However, with no annotations and 0% schema coverage, it lacks behavioral context like permissions or error handling, making it adequate but with 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?
The description mentions 'for a specific application', which aligns with the single parameter 'application_id'. However, with 0% schema description coverage, the schema provides no parameter details. The description adds basic context about the parameter's purpose but doesn't specify format constraints (e.g., integer ID) or where to find the ID, resulting in adequate but incomplete parameter semantics.
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 scheduled interviews for a specific application'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_interviews' (which likely lists all interviews without application filtering) or 'get_interview' (which retrieves a single interview), missing 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 like 'list_interviews' or 'get_interview', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a list operation, implying it's likely read-only, but doesn't confirm this or describe other traits like pagination, rate limits, authentication needs, or what happens if the user_id is invalid. For a tool with zero annotation coverage, this is insufficient.
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 action and resource. There's no wasted language, and it's appropriately sized for a simple list tool, 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 low complexity (one parameter) and the presence of an output schema (which handles return values), the description is somewhat complete. However, with no annotations and minimal parameter explanation, it lacks details on behavioral aspects and usage context, making it only adequate overall.
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 0%, so the description must compensate for undocumented parameters. It mentions 'user_id' implicitly ('granted to a user'), adding some meaning beyond the schema's bare title. However, with one parameter, the baseline is 4, but it doesn't fully explain the parameter's role or constraints, so a score of 3 reflects partial compensation.
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 ('job-level permissions granted to a user'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_future_job_permissions' or 'list_user_roles', which would be needed for 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 'list_future_job_permissions' or 'list_user_roles'. It also doesn't mention prerequisites such as needing a valid user_id or any access requirements, 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.
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 mentions listing and optional filtering, but doesn't disclose behavioral traits such as pagination behavior (implied by parameters but not described), rate limits, authentication requirements, or what constitutes a 'live' post. For a list operation with no annotation coverage, this leaves significant gaps in understanding 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 that front-loads the core functionality ('List all job posts') and adds the optional filtering detail. There is no wasted verbiage, and it's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is minimally adequate. It covers the basic purpose and one parameter hint, but lacks details on usage context, behavioral transparency, and full parameter semantics, leaving room for improvement in guiding the agent.
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 schema provides no parameter descriptions. The description only mentions the 'live' parameter implicitly ('optionally filtered to only live (published) posts'), but doesn't explain the other three parameters (per_page, page, paginate) or their semantics. It adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('job posts'), and specifies the optional filtering capability ('optionally filtered to only live (published) posts'). It distinguishes from siblings like 'get_job_post' (singular) and 'list_job_posts_for_job' (job-specific), but doesn't explicitly contrast them. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving job posts with optional live filtering, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'list_jobs' or 'list_job_posts_for_job'. It mentions the filtering option but doesn't specify scenarios or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a listing operation, which implies read-only behavior, but doesn't mention any constraints like pagination, rate limits, authentication requirements, or what happens when no job posts exist. For a tool with zero annotation coverage, this leaves significant 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 that gets straight to the point with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
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 has an output schema (which reduces the need to describe return values), simple parameters, and no annotations, the description is minimally adequate. However, it lacks important context about usage guidelines and behavioral constraints that would be helpful for an AI agent, especially with no annotations to fill those 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?
The description mentions 'a specific job' which aligns with the single 'job_id' parameter in the schema. However, with 0% schema description coverage, the description doesn't add meaningful details about parameter format, constraints, or examples. It provides minimal semantic context beyond what's obvious from the parameter name.
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 ('List all job posts') and the target resource ('associated with a specific job'), providing a specific verb+resource combination. However, it doesn't differentiate from similar sibling tools like 'list_job_posts' or 'get_job_post_for_job', which would be needed for 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. There are multiple related tools in the sibling list (e.g., 'list_job_posts', 'get_job_post_for_job'), but the description doesn't mention any of them or explain when this specific filtered listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states it's a list operation, implying read-only and non-destructive behavior, but doesn't disclose key traits like pagination handling (implied by parameters but not described), rate limits, authentication needs, or what 'list all' entails (e.g., if it returns all jobs at once or requires pagination). This leaves significant gaps for agent understanding.
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 action ('List all jobs') and adds necessary detail ('with optional filters...'). There is no wasted text, making it appropriately sized 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 8 parameters with 0% schema coverage and no annotations, but with an output schema present, the description is moderately complete. It covers the main filtering aspects but misses pagination and other parameter details. The output schema reduces the need to explain return values, but the lack of behavioral context and incomplete parameter coverage keeps it at an adequate level with 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 0%, so the description must compensate. It mentions optional filters for status, department, office, and dates, which maps to some parameters (status, department_id, office_id, created_after, created_before), but doesn't cover others like per_page, page, or paginate. This adds partial meaning but doesn't fully compensate for the coverage gap, aligning with a baseline score.
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 ('jobs') with scope ('all'), making the purpose specific and understandable. However, it doesn't differentiate from sibling list tools like 'list_job_openings' or 'list_board_jobs', which might have overlapping functionality, 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 mentions optional filters (status, department, office, dates), implying usage for filtered listing, but provides no explicit guidance on when to use this tool versus alternatives like 'list_job_openings' or 'list_board_jobs' from the sibling list. There are no exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List all offers' which implies a read operation, but doesn't specify permissions needed, pagination behavior, rate limits, or what 'all offers' includes (e.g., historical, pending, accepted). For a tool with zero annotation coverage, this leaves significant 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 that gets straight to the point with zero wasted words. It's appropriately sized for a simple list operation and front-loads the essential information.
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 has an output schema (which handles return values) and only one parameter, the description covers the basic purpose adequately. However, with no annotations and 0% schema description coverage, it should provide more behavioral context about permissions, scope, and limitations for a complete 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'on a specific application' which clarifies the purpose of the application_id parameter, but doesn't provide format details, valid ranges, or examples. The description adds some meaning but doesn't fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all offers') and target resource ('on a specific application'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_offers' or 'get_current_offer', which could cause confusion about when to use each.
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 about when to use this tool versus alternatives like 'list_offers' or 'get_current_offer'. The description only states what it does, not when it's appropriate or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states it's a list operation, implying read-only behavior, but doesn't mention permissions, pagination, rate limits, or what 'pending' entails (e.g., status definitions). For a 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 no wasted words, clearly front-loading the core action and optional feature. It's appropriately sized for a simple list tool, making it easy 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 (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks depth for safe and effective use, especially in a context-rich sibling environment.
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 0%, but the description adds minimal value by mentioning the optional 'user_id' filter. It doesn't explain the parameter's semantics beyond what's inferred from the title ('User Id'), such as format or valid values. With one parameter and low schema coverage, this provides basic but incomplete compensation.
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 ('pending approvals') with an optional filter ('by user_id'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_approvals_for_job' or 'list_approvals_for_application', which would be needed for 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 'list_approvals_for_job' or 'list_approvals_for_application' from the sibling list. It mentions optional filtering but doesn't explain use cases or prerequisites, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation ('List all'), but doesn't specify whether this requires authentication, what the output format looks like (though an output schema exists), or any rate limits or constraints. 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, clear sentence with no wasted words, effectively front-loading the core purpose. It's appropriately sized for a simple list operation.
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 parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks depth for full contextual understanding, though not critically so.
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 'a specific question set' which maps to the single parameter 'question_set_id', but with 0% schema description coverage, it doesn't add details like format or constraints beyond what's implied. Since there's only one parameter, the baseline is 4, but the description provides minimal extra value, so a 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 clearly states the action ('List all demographic questions') and the target resource ('belonging to a specific question set'), which provides a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'list_questions' or 'list_question_sets' that might handle different scopes of questions, leaving some ambiguity about when to choose this specific 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 like 'list_questions' or 'list_question_sets', nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 listing scorecards but doesn't describe key behaviors like pagination, sorting, what 'submitted' means, error conditions, or authentication requirements. For a read operation with zero annotation coverage, this leaves significant gaps in understanding 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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information.
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 (1 parameter, read-only listing) and the presence of an output schema (which likely covers return values), the description is minimally adequate. However, with no annotations and incomplete parameter documentation, it lacks details on behavior and context that would make it fully complete for safe and 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 input schema has 1 parameter with 0% description coverage, and the description doesn't add any parameter-specific information beyond implying 'application_id' is needed. It doesn't explain what an 'application_id' is, its format, or where to find it. Given the low schema coverage, the description doesn't compensate adequately, but it at least hints at the parameter's role.
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 ('List all scorecards submitted') and the target resource ('for a specific application'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'list_scorecards' or 'list_scorecards_for_application' (if that's a different tool), which would be needed for 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 'list_scorecards' (which might list all scorecards without filtering by application) or other listing tools. It states the purpose but offers no context about prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a list operation, implying it's read-only and non-destructive, but doesn't cover aspects like pagination, error handling, permissions required, or rate limits. For a 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 no wasted words. It's front-loaded with 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.
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 parameter, read-only operation) and the presence of an output schema (which likely describes the return format), the description is minimally adequate. However, with no annotations and incomplete parameter semantics, it lacks depth for a tool that might involve data retrieval constraints or permissions, leaving room for improvement in contextual coverage.
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 1 parameter with 0% description coverage, and the description adds no details about the 'candidate_id' parameter (e.g., format, sourcing, or validation). Since schema coverage is low, the description fails to compensate, but with only one parameter, the baseline is slightly higher than minimal. It implies the parameter identifies a candidate but provides no further semantics.
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 ('tags applied to a specific candidate'), making the purpose unambiguous. However, it doesn't distinguish this tool from sibling tools like 'list_tags' (which likely lists all tags in the system) or 'list_candidates' (which lists candidates themselves), missing explicit 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 prerequisites (e.g., needing a valid candidate ID), exclusions, or compare it to similar tools like 'list_tags' or 'get_candidate' for tag-related operations, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 list operation, implying read-only behavior, but doesn't mention pagination details (handled by 'per_page' and 'page' parameters), rate limits, authentication needs, or what the output looks like. For a tool with parameters and 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 purpose without any wasted words. It's appropriately sized for a simple list tool, 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.
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 (a read-only list operation), two parameters, no annotations, and an output schema present, the description is minimally adequate. It states what the tool does but lacks details on usage, behavioral traits, or parameter meaning. The output schema likely covers return values, so the description doesn't need to explain those, but it falls short in providing a complete context for effective tool selection.
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 information about the parameters beyond what the input schema provides (two parameters: 'per_page' and 'page' with defaults). Schema description coverage is 0%, so the description doesn't compensate for this gap. However, since there are only two parameters and the schema is straightforward, the baseline score of 3 is appropriate as the description doesn't add value but also doesn't mislead.
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 ('List all') and resource ('user roles available in the organization'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_users' or 'list_custom_fields', which follow similar patterns but target different resources, so it doesn't fully distinguish itself in context.
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_users' for user details or 'list_custom_fields' for other metadata. It lacks explicit context, prerequisites, or exclusions, leaving usage entirely implicit 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.
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 list operation, implying it's likely read-only, but doesn't clarify permissions, rate limits, pagination behavior (beyond what the schema implies), or what happens if filters yield no results. For a tool with 6 parameters and no annotation coverage, this is insufficient.
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 ('List all Greenhouse users') and adds key details about filters. There's no wasted text, making it appropriately sized 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 complexity (6 parameters, no annotations, but an output schema exists), the description is moderately complete. It covers the main purpose and some parameters but lacks behavioral details and full parameter explanations. The output schema reduces the need to describe return values, but the gaps in usage and transparency keep it from being fully adequate.
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 for email and created date ranges, which maps to the 'email', 'created_after', and 'created_before' parameters. However, with 0% schema description coverage and 6 total parameters, it doesn't explain 'per_page', 'page', or 'paginate', leaving significant gaps. The baseline is 3 due to the schema's lack of descriptions, but the description only partially compensates.
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 ('Greenhouse users'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_candidates' or 'get_user', which are related but distinct resources, 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 mentions optional filters for email and created date ranges, which provides some context for usage, but it doesn't offer guidance on when to use this tool versus alternatives (e.g., 'get_user' for a single user or 'list_candidates' for candidate users). No explicit when/when-not or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'revoke' implies a destructive/mutative operation, it doesn't specify whether this requires admin permissions, whether the change is permanent or reversible, what happens if the permission doesn't exist, or what the output looks like. For a permission removal tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 operation and front-loads the core action ('revoke'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description doesn't need to explain outputs. However, for a destructive permission operation with 2 required parameters and no annotations, the description should provide more context about usage scenarios, error conditions, or security implications. It's minimally adequate but leaves 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 0%, so the schema provides no parameter descriptions. The description mentions 'permission ID' which maps to one parameter (job_permission_id), but doesn't explain why both user_id and job_permission_id are required or their relationship. It adds minimal value beyond what's inferable from parameter names alone, earning a baseline score.
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 ('revoke') and target ('user's job permission by permission ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'remove_future_job_permission' or 'change_user_permission_level', which appear to handle related permission operations.
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 to know the permission ID first), nor does it clarify the relationship with tools like 'list_job_permissions' (which might be needed to find the ID) or 'add_job_permission' (the inverse operation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states this is an update operation (implying mutation) but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens when fields are set to null. The mention of specific updatable fields adds some context, but critical behavioral information is missing for a mutation 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 a single, efficient sentence that front-loads the core purpose and lists all updatable fields without unnecessary words. Every element earns its place, making it easy to scan and understand 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 complexity (7 parameters, mutation operation) and the presence of an output schema (which reduces need to describe return values), the description is moderately complete. It covers what fields can be updated but lacks behavioral context (permissions, side effects) and parameter details beyond field names. With no annotations, it should do more to guide safe usage.
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 0%, so the description must compensate. It lists the updatable fields (name, status, department, offices, requisition ID, notes), which maps to 6 of the 7 parameters (excluding job_id). This adds meaningful semantics beyond the schema's generic titles, but doesn't explain data formats, constraints, or the purpose of the required job_id parameter.
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 ('Update') and resource ('a job') with specific fields that can be modified (name, status, department, offices, requisition ID, notes). It distinguishes from siblings like 'create_job' (creation vs. update) and 'update_job_opening' (different resource), but doesn't explicitly differentiate from all update tools like 'update_application' or 'update_candidate'.
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 doesn't mention prerequisites (e.g., needing an existing job ID), when not to use it, or how it relates to similar tools like 'update_job_opening' or 'update_application' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'Update' implies a mutation, it doesn't disclose critical behavioral traits like required permissions, whether changes are reversible, error handling, or rate limits. This leaves significant gaps for a tool that modifies 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, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a straightforward update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, mutation operation) and the presence of an output schema, the description is minimally adequate. However, with no annotations and low schema coverage, it should provide more behavioral context and parameter guidance to be fully 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 description lists the updatable fields (status, close reason, custom fields), which adds meaning beyond the input schema's 0% description coverage. However, it doesn't explain the semantics of these fields (e.g., what values 'status' accepts, what 'close_reason_id' refers to), leaving the agent to infer from the schema alone.
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 ('Update') and the resource ('a job opening's status, close reason, or custom fields'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from similar sibling tools like 'update_job' or 'update_application', which would be needed for 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. With many sibling tools available (e.g., 'update_job', 'update_application'), there's no indication of context, prerequisites, or exclusions 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.
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. While 'Update' implies a mutation operation, the description doesn't mention permission requirements, whether changes are reversible, what happens when only one field is provided, or any rate limits. For a mutation tool with zero annotation coverage, 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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for what it communicates and is perfectly front-loaded.
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 that there's an output schema (which handles return values), no annotations, and moderate complexity (3 parameters, mutation operation), the description is minimally adequate. It states what the tool does but lacks behavioral context and usage guidance that would make it truly complete for an AI 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 description mentions 'name or location' which maps to two of the three parameters, but with 0% schema description coverage, it doesn't fully compensate. The description doesn't explain the office_id parameter (which is required) or clarify that name and location are optional (nullable with defaults). Baseline 3 is appropriate given the schema does the structural 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 action ('Update') and resource ('an office's name or location'), making the purpose immediately understandable. However, it doesn't distinguish this tool from other update tools in the sibling list (like update_department, update_job, update_user), 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. There are many sibling tools for updating different resources (update_department, update_job, etc.), but the description doesn't help an agent understand when this specific office-updating tool is appropriate versus other update operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Delete' implies a destructive mutation, but the description doesn't state whether this requires specific permissions, whether the deletion is permanent or reversible, what happens to associated data, or what the response looks like. For a destructive operation with zero annotation coverage, this is a significant gap in behavioral 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 maximally concise - a single sentence with no wasted words. It's front-loaded with the core action and resource. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations, the description is minimally adequate but has clear gaps. The existence of an output schema helps (so return values are documented elsewhere), but the description doesn't address critical context like permissions needed, irreversible consequences, or relationship to sibling webhook tools. For a deletion operation, more behavioral context would be expected.
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 mention any parameters, while the schema has 1 parameter with 0% description coverage. The baseline is 3 because the schema provides the parameter structure (rule_id as integer), but the description adds no semantic context about what rule_id represents, where to find it, or format requirements. This leaves the agent with incomplete understanding despite the simple schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a webhook routing rule'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'webhook_update_rule' or 'delete_application' tools, which would require mentioning what specifically distinguishes webhook rule deletion from other deletion operations.
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 (like needing an existing rule ID), when deletion is appropriate versus updating, or what happens after deletion. The sibling list includes 'webhook_update_rule' and 'webhook_list_rules' which are clearly related alternatives, but the description doesn't reference them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a list operation but doesn't describe what 'recent' means, whether results are paginated, what authentication is required, rate limits, or the format of returned events. 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 that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information.
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?
For a simple list tool with one parameter and an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter documentation, it lacks important context about behavioral traits and usage scenarios that would make it more helpful to an AI 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 description mentions no parameters, while the schema has one parameter ('limit') with 0% description coverage. Since the description adds no parameter information beyond what the schema provides (which is minimal), and there's only one parameter, the baseline score of 3 is appropriate. The description doesn't compensate for the schema's lack of parameter descriptions.
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 ('List') and resource ('recent webhook events received by the receiver'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'webhook_list_events' or 'webhook_list_rules', which appear to be related webhook operations.
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 doesn't mention sibling tools like 'webhook_list_events' or 'webhook_list_rules', nor does it specify any prerequisites, exclusions, or contextual triggers for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Delete' clearly indicates a destructive operation, but it doesn't specify whether this action is reversible, what permissions are required, whether it sends notifications, or what happens to associated data. For a destructive 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 that communicates the core functionality without any wasted words. It's appropriately sized for a simple deletion operation and gets straight to the point with no unnecessary elaboration.
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?
For a destructive operation with no annotations, the description is minimally adequate but lacks important context about permissions, consequences, and alternatives. The presence of an output schema helps, but the description doesn't explain what the tool returns or confirm successful deletion. It meets basic requirements but leaves significant gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context about the single parameter by specifying 'by ID', which clarifies that the interview_id parameter must be an identifier. With 0% schema description coverage and only one parameter, this minimal addition provides adequate semantic understanding beyond the basic schema type information.
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 resource ('a scheduled interview by ID'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'delete_application' or 'delete_candidate', but the specificity of 'scheduled interview' provides adequate clarity for this tool's unique 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 provides no guidance on when to use this tool versus alternatives like 'update_interview' or 'cancel_interview' (if such tools exist). It mentions 'by ID' which implies the parameter needed, but offers no context about prerequisites, consequences, or appropriate scenarios for deletion versus other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a deletion operation, implying it's destructive, but doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., removing tag from all candidates). For a destructive tool with zero annotation coverage, this is insufficient.
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 a simple operation.
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?
For a destructive tool with no annotations, 0% schema coverage, but with an output schema present, the description is minimally adequate. It identifies the action and parameter purpose but lacks crucial behavioral details (permanence, permissions) and usage context. The output schema may cover return values, but the description doesn't address mutation risks.
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 description mentions 'by ID' which clarifies the purpose of the single parameter 'tag_id' beyond what the schema provides (0% coverage, only shows type integer). However, it doesn't explain where to obtain valid tag IDs (e.g., from list_tags) or format constraints, keeping it from a perfect score.
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 target resource ('a candidate tag by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'remove_tag_from_candidate' or 'create_tag', which would require explicit comparison to achieve 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 'remove_tag_from_candidate' or 'bulk_tag', nor does it mention prerequisites (e.g., needing tag_id from list_tags) or consequences. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get' which implies a read operation, but fails to specify whether it's safe, requires authentication, has rate limits, or what the output entails. This leaves significant gaps for a tool that likely accesses sensitive demographic 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, efficient sentence with no wasted words, clearly front-loading the core functionality. Every part of the sentence contributes directly to understanding the tool's purpose.
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 parameter) and the presence of an output schema, the description is minimally adequate. However, it lacks behavioral context (e.g., permissions, error handling) and doesn't leverage the output schema to hint at return values, leaving room for improvement in guiding the agent.
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 description adds meaning by specifying that the parameter 'answer_id' is used to retrieve 'a single demographic survey answer', which clarifies the parameter's purpose beyond the schema's generic 'Answer Id' title. With 0% schema description coverage and only one parameter, this compensates adequately, though it doesn't detail format 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 verb ('Get') and resource ('a single demographic survey answer by ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_answers' or 'get_answer_option', which would require a 5.
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 'list_answers' or 'get_answer_option', nor does it mention prerequisites or context. It merely states what the tool does without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Get' implying a read operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or whether it returns all metadata or a subset. The description is minimal and lacks necessary context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the purpose and lists specific fields without unnecessary elaboration, making it easy 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 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a read tool with no annotations, it should ideally mention safety (e.g., non-destructive) or output format hints to compensate for the lack of structured behavioral data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info beyond the schema, which is appropriate here, earning a baseline score of 4 for this dimension.
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 ('job board metadata') with specific fields listed (name, content, departments, offices). It distinguishes from siblings like 'get_board_department' or 'get_board_job' by focusing on overall metadata rather than specific components, though it doesn't explicitly name alternatives.
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_board_department' or 'get_board_office'. The description implies usage for retrieving general board metadata but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a read operation ('Get'), implying it's likely non-destructive, but doesn't specify permissions, rate limits, error conditions, or the format of the returned custom location data. This leaves significant gaps for a tool that retrieves 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy 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 has an output schema (which likely defines the return structure), the description doesn't need to detail return values. However, for a read operation with no annotations and minimal parameter guidance, it's adequate but lacks depth on behavioral aspects like error handling or data scope, leaving room for improvement.
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 description mentions 'a specific job post', which aligns with the single parameter 'job_post_id' in the input schema. Since there's only one parameter and schema description coverage is 0%, the description adds meaningful context by clarifying that the ID refers to a job post, compensating for the lack of schema 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 action ('Get') and resource ('custom location data for a specific job post'), making the purpose understandable. However, it doesn't explicitly differentiate from potential siblings like 'get_job_post' or 'get_job_post_for_job', which might also retrieve job post data but with different scopes or fields.
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 doesn't mention prerequisites, such as needing an existing job post ID, or contrast it with other tools that might handle location data differently, 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.
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 retrieves a single stage by ID. It lacks behavioral details such as whether this is a read-only operation, what happens with invalid IDs, error handling, or response format. For a tool with zero annotation coverage, this is insufficient.
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 no wasted words. It's front-loaded with the core action and resource, making it easy 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 simplicity (1 parameter, output schema exists) and lack of annotations, the description is minimally adequate but incomplete. It covers the basic purpose but misses behavioral context and usage guidelines that would help an agent invoke it correctly.
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 description specifies 'by ID', which clarifies the purpose of the single parameter 'job_stage_id' beyond the schema's title 'Job Stage Id'. With 0% schema description coverage, this adds meaningful context, though it doesn't detail ID format 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 ('Get') and target resource ('a single job stage by ID'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_job_stages' or 'list_job_stages_for_job' which retrieve multiple stages, missing an opportunity for full 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a valid job_stage_id) or compare it to sibling tools like 'list_job_stages', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 authentication requirements, rate limits, error conditions, or what happens if the question_id doesn't exist. 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 that communicates the core purpose without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and an output schema available, the description is reasonably complete. The presence of an output schema means the description doesn't need to explain return values. However, the lack of annotations and minimal parameter guidance keeps it from being fully comprehensive.
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 'by ID' which clarifies the purpose of the single parameter, but with 0% schema description coverage, it doesn't provide format details, valid ranges, or examples. Since there's only one parameter, the baseline is higher, but the description adds minimal value beyond what's obvious from the parameter name.
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 demographic question by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar siblings like 'get_question_set' or 'list_questions', which would require more specificity for 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 'list_questions' or 'get_question_set', nor does it mention prerequisites or constraints. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions returning 'source and referrer metadata,' which adds some behavioral context beyond the basic retrieval action. However, it lacks details on error handling, authentication needs, rate limits, or whether the operation is idempotent—critical 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 front-loads the core action and outcome. Every word contributes to understanding the tool's purpose, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the basic operation and return metadata. However, with no annotations, it could benefit from more behavioral context like error cases or usage constraints.
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 0%, but the description clarifies that the 'token' parameter is used to identify the tracking link. This adds meaning beyond the schema's basic type information. However, it doesn't explain the token's format, source, or constraints, leaving gaps in 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 action ('Get') and resource ('tracking link'), specifying retrieval by token. It distinguishes from siblings like 'post_tracking_link' by focusing on retrieval rather than creation. However, it doesn't explicitly contrast with other get_* tools that might retrieve different resources.
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 doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 whether this is a read-only operation, if there are rate limits, pagination behavior, or what authentication is required. For a tool with zero annotation coverage, this is insufficient.
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 what the tool does. There's no wasted language or unnecessary elaboration, making it perfectly concise for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and annotations are absent, the description provides the basic purpose but lacks behavioral context. It's minimally adequate for a simple listing tool but doesn't address usage differentiation or operational constraints.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose without redundancy.
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 ('demographic survey answer options'), making the purpose immediately understandable. It doesn't specifically differentiate from its sibling 'list_answer_options_for_question', but the general scope is clear.
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 about when to use this tool versus alternatives like 'list_answer_options_for_question' or 'get_answer_option'. The description implies a broad listing without filtering, but this isn't explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'List departments' implies a read-only operation, but the description doesn't specify whether this requires authentication, returns paginated results, includes metadata, or has any rate limits. 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 with no parameters, and the information is front-loaded with the core purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and multiple similar sibling tools, it should provide more context about what distinguishes this particular department listing from others. The existence of an output schema reduces the need to describe return values, but behavioral context remains insufficient.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the empty input structure. The description appropriately doesn't mention parameters since none exist, maintaining focus on the tool's purpose rather than unnecessary parameter 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 action ('List') and resource ('departments on the job board'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_departments' or 'get_board_department', which appear to serve related but potentially different 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 like 'list_departments' or 'get_board_department'. There's no mention of prerequisites, context, or exclusions that would help an agent choose between these similar-sounding tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'List' implies a read-only operation, the description doesn't specify whether this requires authentication, returns paginated results, has rate limits, or provides any error handling details. It lacks critical behavioral context for a tool in a job board system.
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 conveys the core purpose without unnecessary words. It's front-loaded with the essential information and contains no redundant or verbose elements.
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 has 0 parameters, 100% schema coverage, and an output schema exists, the description's minimal approach is somewhat adequate. However, for a tool in a complex job board system with many siblings, it lacks context about what 'academic disciplines' entails (e.g., categories, IDs, names) and how it relates to other list tools, leaving gaps in completeness.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to compensate for any parameter gaps, and it appropriately doesn't mention parameters, earning a baseline score of 4 for not 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 clearly states the action ('List') and resource ('academic disciplines available on the job board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_disciplines' or 'list_board_departments', which might have overlapping scopes or different contexts.
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 'list_disciplines' and 'list_board_departments' available, there's no indication of whether this tool is for a specific board context, filtering criteria, or other distinguishing use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 ('List') but doesn't describe return format, pagination, permissions required, or error conditions. For a read operation with zero annotation coverage, this leaves significant gaps in understanding 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 no wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for a simple list operation.
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, has output schema), the description is minimally adequate. However, with no annotations and sibling tools that suggest potential overlap (e.g., 'list_offices', 'get_board_office'), it lacks contextual differentiation. The output schema will handle return values, but behavioral aspects like permissions or pagination remain undocumented.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters, earning a baseline score of 4 for this context.
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 ('offices on the job board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_offices' or 'get_board_office', which appear to serve similar but potentially distinct 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?
No guidance is provided on when to use this tool versus alternatives like 'list_offices' or 'get_board_office'. The description lacks context about prerequisites, appropriate scenarios, or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a read operation ('List'), implying it's likely safe and non-destructive, but doesn't specify any behavioral traits like pagination, rate limits, authentication needs, or what 'available on the job board' entails. This leaves significant gaps in understanding 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, clear sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and efficiently communicates the essential information, 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 has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and a sibling tool 'list_schools' that might overlap, it lacks context on differentiation and behavioral details, making it incomplete for optimal agent use without additional inference.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, warranting a baseline score of 4 as it avoids unnecessary complexity.
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 ('List') and resource ('schools available on the job board'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from the sibling tool 'list_schools', which might serve a similar function but with different scope or parameters, leaving room for 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, such as 'list_schools' or other list_* siblings. There are no explicit instructions on context, prerequisites, or exclusions, 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.
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 indicates this is a read operation ('List'), but doesn't mention authentication requirements, rate limits, pagination, error conditions, or what the output contains. For a tool with an output schema, some behavioral context is missing.
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. Every word earns its place, with no redundant or vague phrasing.
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 has an output schema (which handles return values) and only one parameter, the description is reasonably complete for a simple lookup tool. However, without annotations and lacking usage guidelines or behavioral details, it leaves gaps in understanding when and how to use it effectively.
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 description doesn't explicitly mention the 'user_id' parameter, but with 0% schema description coverage and only one parameter, it's clear from context that listing a user's permissions requires specifying which user. The description compensates adequately by defining what 'future job permissions' means, though it could explicitly reference the parameter.
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 ('user's future job permissions'), with additional context about what these permissions are ('auto-applied to new jobs by office/department'). However, it doesn't explicitly differentiate from sibling tools like 'list_job_permissions' or 'get_user', which might list different types of permissions.
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 doesn't mention prerequisites (e.g., user must exist), exclusions, or compare it to similar tools like 'list_job_permissions' or 'get_user' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a read operation ('List') but doesn't mention potential side effects, authentication needs, rate limits, or the return format. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, front-loading the key action and resource. It's appropriately sized for a simple tool with no parameters, making it highly efficient and easy to parse.
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, output schema exists), the description is minimally adequate. However, with no annotations and a read operation, it could benefit from mentioning behavioral aspects like pagination or sorting. The output schema likely covers return values, but the description doesn't add enough context for full completeness.
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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it appropriately focuses on the action. A baseline of 4 is given as it efficiently handles the lack of parameters without unnecessary elaboration.
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 the resource 'demographic survey questions' with the scope 'all', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_questions_for_question_set', which might handle a subset, leaving room for potential confusion.
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_questions_for_question_set' for filtered lists or 'get_question' for individual details. It lacks context on prerequisites or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 list operation, implying read-only behavior, but doesn't mention potential side effects, rate limits, authentication needs, or output format. For a tool with zero annotation coverage, this is insufficient.
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 no wasted words. It's front-loaded with the core action and resource, 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 has 0 parameters, 100% schema coverage, and an output schema exists, the description's job is simplified. However, with no annotations, it should ideally add more behavioral context (e.g., pagination, sorting, or data format) to compensate. The current description is minimal but not fully complete for a list operation in a complex system.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately focuses on the tool's purpose without redundant parameter information, earning a high score.
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 demographic survey question sets'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_questions' or 'get_question_set', which could be confusing for an agent trying to select the right 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?
No guidance is provided on when to use this tool versus alternatives like 'list_questions' or 'get_question_set'. The description lacks context about prerequisites, timing, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'retrieve' implies a read operation, it doesn't specify authentication requirements, rate limits, what 'current' means in context, or whether this is a lightweight vs heavy operation. The mention of 'via Ingestion API' adds minimal context but doesn't explain practical implications.
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 includes just enough context about the API source. Every word earns its place in this minimal but complete statement.
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?
For a zero-parameter tool with an output schema, the description covers the basic purpose adequately. However, given the lack of annotations and the presence of similar sibling tools (get_user, list_users), it should provide more differentiation and usage context. The output schema will handle return values, but behavioral aspects remain underspecified.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the empty parameter set. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is appropriate for zero-parameter tools when the schema handles documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieve') and target ('current partner user'), providing a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'get_user' or 'list_users' that might retrieve user information differently, preventing 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 'get_user' or 'list_users'. It doesn't mention prerequisites, context requirements, or any 'when-not-to-use' scenarios, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'List all' implies a read-only operation that returns all items, but it doesn't specify whether results are paginated, sorted, filtered, or if there are rate limits or authentication requirements. For a 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 no wasted words. It's front-loaded with the core action ('List all') and resource ('webhook routing rules'), making it immediately understandable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and a read operation, it should ideally mention behavioral aspects like pagination or sorting. The output schema helps, but the description could provide more context about what 'all' entails (e.g., unfiltered, complete list).
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it correctly doesn't mention any parameters. A baseline of 4 is appropriate since the schema handles all parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all webhook routing rules' clearly states the verb ('List') and resource ('webhook routing rules'), making the purpose unambiguous. It distinguishes from siblings like 'webhook_list_events' or 'webhook_list_recent' by specifying 'routing rules', but doesn't explicitly contrast with 'webhook_create_rule' or 'webhook_update_rule' beyond the verb difference.
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, typical use cases, or when to choose this over other webhook-related tools like 'webhook_list_events' or 'webhook_list_recent'. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the optional email invite, which adds some behavioral context. However, it lacks critical details: it doesn't specify required permissions, whether the operation is idempotent, what happens on duplicate emails, rate limits, or the response format. 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 that front-loads the core purpose and includes the optional feature. There is no wasted language, and it's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which should cover return values), the description doesn't need to explain outputs. However, for a mutation tool with no annotations and 0% schema description coverage, the description is incomplete: it lacks permission requirements, error conditions, and behavioral nuances. It provides a basic overview but leaves gaps in critical operational 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 0%, so the schema provides no descriptions for parameters. The description adds value by naming the parameters (first/last name and email) and hinting at the optional 'send_email' parameter's purpose ('sending an invite'). However, it doesn't explain parameter constraints (e.g., email format, name length) or the default behavior of 'send_email' (true by default per schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new Greenhouse user') and specifies the core data fields (first/last name and email). It distinguishes from sibling tools like 'add_email_to_user' or 'update_user' by focusing on user creation. However, it doesn't explicitly differentiate from 'enable_user' or other user-related tools beyond the creation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'optionally sending an invite,' suggesting this tool is for initial user setup. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'update_user' or 'enable_user,' nor does it mention prerequisites (e.g., required permissions) or exclusions (e.g., cannot create duplicate users).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get' which implies a read operation, but doesn't specify if it requires authentication, returns errors for invalid IDs, includes rate limits, or what the output contains (though an output schema exists). For a read tool with zero annotation coverage, this is a significant gap in 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, clear sentence with no wasted words. It front-loads the core action ('Get a single job post') and specifies the key constraint ('by ID'), making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read operation) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the basic purpose and parameter use. However, it lacks behavioral details like error handling or authentication needs, which are important even with an output schema, preventing a perfect score.
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 description adds meaning by specifying that the parameter 'job_post_id' is used to retrieve 'a single job post', clarifying its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this compensation is effective. However, it doesn't detail ID format or validation rules, keeping it from a perfect score.
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 job post by ID', making the purpose specific and understandable. It distinguishes this from sibling tools like 'list_job_posts' or 'get_job_post_for_job' by specifying retrieval of a single item via ID. However, it doesn't explicitly differentiate from other 'get_' tools like 'get_job' or 'get_job_opening', which slightly limits 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 prerequisites (e.g., needing a valid job_post_id), exclusions, or comparisons to similar tools like 'get_job' or 'list_job_posts'. This lack of context leaves the agent to 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.
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 it's a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or add details like rate limits, authentication needs, or output format. For a tool with zero annotation coverage, this is insufficient.
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 directly states the tool's purpose without unnecessary words. It's front-loaded and efficient, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description is reasonably complete. However, it could benefit from more behavioral context or usage guidelines to fully compensate for the lack of annotations.
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 tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add any parameter details, which is appropriate here, earning a baseline score of 4 for adequately handling the lack of parameters.
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 ('List') and the resource ('degree types available on the job board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_degrees' or 'list_board_schools', which might list different types of educational data.
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 doesn't mention prerequisites, context, or compare it to similar tools like 'list_degrees' or 'list_board_schools', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List all openings' but doesn't disclose behavioral traits such as pagination, rate limits, authentication requirements, or what 'openings' entail (e.g., are they job postings, stages, or positions?). The phrase 'optionally filtered by status' hints at functionality but lacks depth on how filtering works or error handling.
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 action ('List all openings for a job') and appends optional functionality. There is zero waste or redundancy, making it highly concise and well-structured for quick comprehension.
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 has an output schema (which reduces need to describe return values) but no annotations and low schema coverage, the description is minimally adequate. It covers the basic purpose and hints at parameters but lacks details on behavior, error cases, or integration with sibling tools. For a read-only list tool, it's passable but could be more informative.
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 0%, so the schema provides no parameter descriptions. The description adds minimal semantics by mentioning 'filtered by status (open/closed)', which clarifies the 'status' parameter's purpose and possible values. However, it doesn't explain 'job_id' (e.g., what constitutes a valid ID) or provide details on parameter interactions, leaving gaps in 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 action ('List all openings') and resource ('for a job'), making the purpose immediately understandable. It distinguishes itself from siblings like 'list_jobs' or 'list_job_posts' by focusing on openings within a specific job. However, it doesn't explicitly differentiate from 'list_job_stages_for_job' or 'list_approvals_for_job', which are also job-specific list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning optional filtering by status, suggesting it's for retrieving openings with possible status constraints. However, it provides no explicit guidance on when to use this tool versus alternatives like 'list_jobs' (for job listings) or 'list_job_openings' (if there were multiple opening-related tools). No prerequisites, exclusions, or comparison to siblings are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'preserving the primary's record,' hinting at non-destructive behavior for the primary, but fails to clarify critical aspects: whether the duplicate is deleted or archived, what happens to associated data (e.g., attachments, notes), permission requirements, or error conditions like invalid IDs.
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 action ('merge a duplicate candidate into a primary candidate') and adds a key behavioral note ('preserving the primary's record') without unnecessary words, making it easy 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 complexity (a mutation operation merging records), no annotations, and an output schema present (which may cover return values), the description is moderately complete. It states the purpose and a key behavior but misses details on side effects, permissions, and error handling, which are crucial for safe use in a candidate management 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 0%, but the description adds minimal semantics by implying 'primary_candidate_id' and 'duplicate_candidate_id' refer to candidates to merge. However, it doesn't explain parameter roles beyond the schema's titles (e.g., which candidate survives), format details, or validation rules, leaving gaps in understanding.
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 clearly states the specific action ('merge a duplicate candidate into a primary candidate') and the resource involved ('candidate'), distinguishing it from sibling tools like 'delete_candidate' or 'update_candidate' by focusing on merging duplicates rather than deletion or general updates.
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 'delete_candidate' for removing duplicates or 'update_candidate' for manual merging. It lacks context about prerequisites, like ensuring candidates are actual duplicates, or exclusions, such as not merging active applications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses the dry-run nature (non-destructive) and that it operates on the most recent event, which is useful. However, it doesn't mention permissions, rate limits, error handling, or what the output looks like, leaving gaps in behavioral understanding.
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 two sentences that are front-loaded and waste no words. Every phrase ('Dry-run a rule', 'most recent matching event', 'Shows what would happen') directly contributes to understanding the tool's purpose and behavior.
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 moderate complexity (testing rules), no annotations, and an output schema present, the description is minimally adequate. It covers the core purpose and dry-run behavior but lacks details on parameters, error cases, and integration with sibling tools, making it incomplete for full contextual 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 input schema has 0% description coverage, with one parameter 'rule_id' undocumented. The description adds no information about this parameter—such as what a rule ID is, where to find it, or format constraints—failing to compensate for the schema's lack of detail.
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 ('Dry-run a rule') and the target ('against the most recent matching event'), with the outcome ('Shows what would happen'). It uses specific verbs and resources, but doesn't explicitly differentiate from sibling tools like webhook_list_rules or webhook_update_rule, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for testing rules without execution, but provides no explicit guidance on when to use this tool versus alternatives like webhook_list_recent or webhook_create_rule. It lacks context on prerequisites or exclusions, leaving usage somewhat open to interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mention authentication requirements, error handling (e.g., what happens if the ID is invalid), rate limits, or response format. For a tool with no 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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse. 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.
Completeness4/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 parameter, no annotations, but with an output schema), the description is reasonably complete. The output schema likely covers return values, reducing the need for description details. However, for a tool with no annotations, more behavioral context (e.g., error cases, permissions) would enhance completeness, though the concise purpose statement suffices for basic 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 mentions 'by ID', which aligns with the single parameter 'interview_id' in the schema. However, schema description coverage is 0%, so the schema provides no additional parameter details. The description adds minimal semantics (it's an ID parameter) but doesn't specify format constraints (e.g., integer type, valid ranges) or examples, resulting in adequate but incomplete parameter guidance.
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 single scheduled interview by ID'), making the purpose unambiguous. It distinguishes from sibling tools like 'list_interviews' by specifying retrieval of a single item. However, it doesn't explicitly differentiate from other get_* tools (e.g., 'get_application', 'get_candidate'), which follow the same pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to retrieve a specific interview by its ID, but provides no explicit guidance on when to choose this over alternatives like 'list_interviews' or 'list_interviews_for_application'. No prerequisites, exclusions, or comparative context are mentioned, leaving usage contextually inferred rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'List all' suggests a read-only operation that returns multiple items, the description doesn't mention important behavioral aspects like pagination, rate limits, authentication requirements, or what happens when no fields match the filter. For a listing 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 perfectly concise at 11 words, front-loading the core purpose ('List all custom fields') and efficiently adding the optional filtering capability in a parenthetical. Every word serves a purpose with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple listing tool with one optional parameter and an output schema exists (which handles return value documentation), the description provides adequate context for basic usage. The combination of clear purpose, parameter hint, and output schema coverage makes this reasonably complete for its complexity level, though behavioral transparency could be improved.
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 0%, so the schema provides no parameter documentation. The description compensates by mentioning the 'field_type' parameter and providing examples of possible values ('candidate, job, etc.'), which adds meaningful context beyond the bare schema. However, it doesn't explain the parameter's optional nature or provide complete enumeration of all possible field types.
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 ('List all custom fields') and resource ('custom fields'), making the purpose immediately understandable. It distinguishes this as a listing operation rather than creation or deletion, which is appropriate given sibling tools like 'create_custom_field' and 'delete_custom_field'. However, it doesn't explicitly differentiate from other list operations like 'list_custom_field_options'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning the optional 'field_type' filter parameter, suggesting this tool can be used when filtering by field type is needed. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_custom_field' (for a single field) or provide context about when filtering is appropriate versus retrieving all fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates a mutation ('unreject') but lacks details on permissions required, whether the action is reversible, rate limits, or what 'active status' entails. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
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 front-loads the core action and outcome, 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.
Completeness3/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 with no annotations), the description is minimal but covers the basic purpose. An output schema exists, so return values need not be explained. However, for a mutation tool, more behavioral context (e.g., permissions, side effects) would improve completeness, making it adequate but with clear gaps.
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 description does not mention parameters, but schema description coverage is 0% with only one parameter ('application_id'). Since there are zero parameters described in the schema, the baseline is 4, as the description need not compensate for missing param info but also adds no specific parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('unreject'), the target resource ('a previously rejected application'), and the outcome ('returning it to active status'). It precisely distinguishes this tool from sibling tools like 'reject_application' and 'advance_application' by focusing on reversal of rejection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('previously rejected application') but does not explicitly state when to use this tool versus alternatives like 'advance_application' or 'update_application'. No exclusions or prerequisites are mentioned, leaving some ambiguity about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it mentions that 'forward' action_type requires action_url, it doesn't address important behavioral aspects: whether this is a mutating operation (likely yes, but not stated), what permissions are needed, whether there are rate limits, what happens on success/failure, or what the output contains. For a creation 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 extremely concise with just two sentences that pack substantial information. Every word earns its place: the first sentence states the purpose and key parameter semantics, the second explains action_type options and their requirements. There's zero wasted text, and the information is front-loaded effectively.
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 has 5 parameters with 0% schema coverage but an output schema exists, the description does well on parameter semantics but lacks behavioral context. For a creation tool with no annotations, it should address mutation implications, permissions, or typical outcomes. The existence of an output schema means return values are documented elsewhere, but the description could better prepare the agent for using this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does so excellently. It explains event_type can be specific or '*' for all events, clarifies action_type has two options ('forward' or 'log'), and specifies that 'forward' requires action_url. This adds crucial semantic meaning beyond the bare schema, covering 3 of the 5 parameters meaningfully.
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 clearly states the specific action ('Create a webhook routing rule') and identifies the resource being created. It distinguishes from sibling tools like webhook_delete_rule, webhook_update_rule, and webhook_list_rules by specifying this is a creation operation. The description goes beyond just restating the name by explaining what kind of rule is being created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by explaining parameter semantics (event_type can be '*' for all events, action_type options and their requirements). However, it doesn't explicitly state when to use this tool versus alternatives like webhook_update_rule or webhook_delete_rule, nor does it mention prerequisites or typical use cases for creating routing rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates this is a read operation ('List'), but does not disclose behavioral traits like rate limits, authentication needs, or response format details. The description adds basic context about what is listed but lacks deeper behavioral 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 key information ('List all 27+ Greenhouse webhook event types with descriptions') with zero wasted words. It is appropriately sized for a no-parameter tool and earns its place clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, an output schema exists, and no annotations, the description is reasonably complete for its purpose. It specifies what is listed and the scope ('27+ Greenhouse webhook event types'), though it could benefit from mentioning the output schema's role or additional context like authentication requirements.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is appropriate given the lack of parameters, warranting a baseline score above minimum viable.
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 clearly states the specific action ('List all') and resource ('27+ Greenhouse webhook event types with descriptions'), distinguishing it from sibling tools like webhook_list_rules or webhook_list_recent. It precisely communicates what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing webhook event types, but does not explicitly state when to use this tool versus alternatives like webhook_list_rules or webhook_setup_guide. No guidance on prerequisites or exclusions is provided, leaving usage context partially inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that tags are created if they don't exist, processing is sequential with rate-limit delays, and returns success/failure counts. This covers key operational traits like side effects and performance characteristics, though it doesn't specify exact rate limits or error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage examples, parameter guidance, and behavioral notes in compact sentences. Every sentence adds value without redundancy, making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch mutation with rate limits), no annotations, and an output schema present (which likely covers return values), the description does well by explaining use cases, behavior, and parameters. It could improve by detailing error cases or prerequisites, but it provides sufficient context for effective tool selection and 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 0%, so the description must compensate. It explains that 'candidate_ids' is a list of IDs and 'tag_name' is the tag name (created if missing), adding basic meaning. However, it doesn't provide details on ID formats, tag name constraints, or list size limits, leaving some parameter semantics unclear despite the baseline being lowered due to poor schema coverage.
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 clearly states the specific action ('Add a tag to multiple candidates'), resource ('candidates'), and scope ('in one call'). It distinguishes from sibling 'add_tag_to_candidate' by emphasizing batch processing versus single-candidate tagging, making the purpose unambiguous.
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 for when to use this tool ('to tag a batch of sourced candidates, mark candidates from a hiring event, or categorize candidates for reporting'), offering practical scenarios. However, it does not explicitly state when NOT to use it or mention the single-candidate alternative ('add_tag_to_candidate') by name, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses that the tool returns base64-encoded content for binary files or plain text, which is useful behavioral information. However, it doesn't mention potential rate limits, authentication needs, error conditions, or file size limitations, leaving gaps for a download 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 efficiently structured in three sentences: the first states the purpose, the second provides usage context and examples, and the third explains the return behavior. Each sentence adds value without redundancy, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with no schema descriptions and an output schema present, the description does a good job covering the tool's purpose, usage, and return format. However, as a download tool with no annotations, it could benefit from mentioning authentication requirements or error handling to be fully complete for agent 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 0% description coverage, so the description must compensate. It explains that the 'url' parameter should be 'from a candidate's attachments list', adding meaningful context beyond the schema's basic string type. This clarifies the source and format expected, though it could specify URL validation or examples.
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 clearly states the specific action ('Download content') and resource ('from a Greenhouse attachment URL'), with examples of what can be downloaded (resumes, cover letters, etc.). It distinguishes itself from sibling tools like 'add_attachment' or 'read_candidate_resume' by focusing on downloading from URLs rather than creating attachments or reading resumes directly.
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 ('Pass the URL from a candidate's attachments list'), but does not explicitly state when not to use it or name alternatives. For example, it doesn't contrast with 'read_candidate_resume' which might handle resume content differently, though the context is implied through the URL requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates this is a read operation ('List') but doesn't disclose behavioral aspects like pagination, rate limits, authentication requirements, or error conditions. The description is minimal but doesn't contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states the tool's function, the second provides usage guidance. There's zero wasted language, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple read operation with 1 parameter and an output schema exists, the description is reasonably complete. It covers purpose and usage guidelines well. However, with no annotations and 0% schema description coverage, it could benefit from more behavioral context about what the output contains or any limitations.
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 0%, but the description mentions 'for a specific job' which implies the job_id parameter. However, it doesn't explain what format the job_id should be, where to find it, or any constraints. With 1 parameter and no schema descriptions, the description adds minimal semantic value beyond what's obvious from the tool name.
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 clearly states the specific action ('List all interview stages') and resource ('for a specific job'), using precise verb+resource phrasing. It distinguishes from sibling 'pipeline_summary' by specifying this tool focuses only on stages for a single job rather than a full pipeline view with candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative tool ('pipeline_summary') for when a full pipeline view with candidates grouped by stage is needed. This gives clear guidance on when to use this tool versus its sibling, establishing proper context boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates this is a mutation tool ('Move'), implies it may skip workflow stages, and mentions a requirement ('Requires both from_stage_id and to_stage_id'). However, it lacks details on permissions, side effects, error conditions, or what the output schema returns, leaving behavioral gaps for a mutation 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 front-loaded with the core purpose, followed by usage examples and distinctions. Every sentence adds value: the first defines the action, the second provides context and prerequisites, and the third clarifies alternatives. There is no redundant or verbose content.
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 mutation nature, 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers purpose, usage, and parameter roles adequately, but lacks behavioral details like permissions, effects, or error handling. The output schema mitigates some gaps, but more context would improve completeness for a stage-skipping operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'application_id' identifies the candidate application, 'from_stage_id' and 'to_stage_id' specify the source and target stages, and clarifies that both stage IDs are required for skipping stages. This adds meaningful context beyond the bare schema, though it doesn't detail ID formats or validation rules.
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 clearly states the specific action ('Move an application to a SPECIFIC stage within the SAME job') and distinguishes it from sibling tools by explicitly contrasting with 'advance_application' for sequential advancement. It provides concrete examples (e.g., skipping from 'Application Review' to 'Onsite'), making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use this tool ('skip stages,' 'jump a candidate to any stage') and when not to ('For sequential advancement to the next stage, use advance_application instead'). It clearly names the alternative tool, providing direct guidance on tool selection without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 mentions optional email sending and references 'list_rejection_reasons' for parameter values, but doesn't disclose critical behavioral traits like whether this action is reversible (though 'unreject_application' exists as a sibling), permission requirements, or rate limits. The description adds some context but leaves significant gaps for a mutation 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 efficiently structured in three sentences with zero waste. The first sentence states the core purpose, the second explains parameter usage, and the third provides the key alternative. Every sentence earns its place by adding essential information.
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?
For a mutation tool with 4 parameters, 0% schema coverage, no annotations, but with an output schema, the description does reasonably well. It covers purpose, guidelines, and parameter semantics adequately, but lacks behavioral transparency about reversibility, permissions, or side effects. The existence of an output schema helps, but more behavioral context would be needed for full completeness.
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?
With 0% schema description coverage, the description compensates well by explaining the purpose of three parameters: 'rejection_reason_id' (from list_rejection_reasons), 'notes' (for internal context), and 'rejection_email' (to trigger email notification). It doesn't cover 'application_id' semantics, but provides meaningful context for the other three parameters beyond what the bare schema offers.
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 clearly states the specific action ('Reject a single application') and resource ('application'), distinguishing it from the sibling 'bulk_reject' tool mentioned. It provides a verb+resource combination that is unambiguous and directly addresses 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Reject a single application') versus alternatives ('For bulk rejections, use bulk_reject instead'). It provides clear context for usage and explicitly names the alternative tool, offering complete guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly indicates this is a mutation operation ('Transfer', 'Moves'), which is helpful. However, it doesn't mention potential side effects, permission requirements, rate limits, or what happens to the application's history. The description adds basic behavioral context but leaves important operational details unspecified.
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 perfectly structured with three sentences that each earn their place: first states the core purpose, second provides usage context, third clarifies parameters and exclusions. No wasted words, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations but has an output schema, the description provides good context about what the tool does and when to use it. It covers the key operational aspects but could benefit from mentioning authentication requirements or potential side effects. The existence of an output schema reduces the need to describe return values.
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?
With 0% schema description coverage and 3 parameters, the description adds significant value by explaining the purpose of 'new_job_id' ('to a DIFFERENT JOB') and 'new_stage_id' ('optionally into a specific stage'). It doesn't explain 'application_id' or provide format details, but the context about what gets moved where compensates well for the schema gap.
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 clearly states the specific action ('Transfer an application to a DIFFERENT JOB entirely') and distinguishes it from sibling tools like 'move_application_same_job' and 'advance_application'. It explicitly defines the verb (transfer/move) and resource (application) with precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when a candidate applied to the wrong role or a better fit opens up') and when not to use it ('NOT for moving between stages in the same job'), naming specific alternatives ('move_application_same_job' or 'advance_application'). This creates clear boundaries for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 the return format ('full profile' and 'candidate record directly from the Greenhouse API'), which adds useful context. However, it doesn't disclose behavioral aspects like authentication requirements, rate limits, error conditions, or whether this is a read-only 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?
Three sentences with zero waste: first states purpose, second provides usage guidelines, third clarifies return source. Each sentence earns its place and the description is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (single parameter, exact-match search) and the presence of an output schema, the description is reasonably complete. It covers purpose, usage, and return format. However, without annotations, it could better address behavioral aspects like authentication or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the 'email' parameter's purpose ('exact email address') and constraint ('exact match'). With only one parameter, this provides adequate semantic context beyond the bare schema.
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 clearly states the specific action ('Search for a candidate by exact email address') and resource ('candidate'), distinguishing it from siblings like 'search_candidates_by_name' and 'get_candidate' by specifying the exact-match email lookup method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this when you have a candidate's email and need their full profile.' This provides clear context for choosing this tool over alternatives like name-based search or general candidate listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 explains what the tool does (aggregates applications, calculates metrics) but lacks details on behavioral traits like data freshness, permission requirements, rate limits, or error handling. It's adequate but has clear gaps for a data analysis 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 well-structured and front-loaded: purpose first, then usage examples, then parameter guidance. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, analysis function) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, usage, and parameters well, though could benefit from more behavioral context given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively explains both parameters: 'job_id' for specific job analysis vs. org-wide, and 'created_after' for time window limitation with format example. This adds crucial meaning beyond the bare schema.
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 clearly states the tool's purpose with specific verbs ('analyze', 'aggregates', 'calculates') and resources ('candidate sources', 'applications by source'). It distinguishes from siblings by focusing on source effectiveness metrics, unlike other tools that handle applications, candidates, or jobs directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with concrete examples ('when asked "which sources are working?" or "where should we invest recruiting budget?"'). It distinguishes from siblings by specifying this tool is for analyzing source performance, not general candidate or job operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 clearly indicates this is a read/analysis operation (not a mutation) by using 'calculate' and 'analyzes,' which is helpful. However, it doesn't disclose important behavioral aspects like whether it requires specific permissions, how it handles data freshness, pagination, or error conditions for invalid inputs. The description adds basic context but lacks depth for a tool with no annotation support.
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 perfectly structured and concise. The first sentence states the core purpose, followed by usage examples, then the computation details, and finally parameter guidance. Every sentence earns its place with no wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signals indicate 'Has output schema: true'), the description doesn't need to explain return values. It adequately covers the tool's purpose, usage, and basic parameter guidance. However, with no annotations and incomplete parameter documentation (missing created_after), there are gaps in behavioral transparency and parameter semantics that prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics of the job_id parameter ('for a specific role or omit for org-wide metrics'), which is valuable. However, it doesn't mention the created_after parameter at all, leaving one of the two parameters completely undocumented. The description adds meaningful context for one parameter but misses the other.
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 clearly states the specific action ('calculate time-to-hire metrics') and the resource ('hired candidates'), distinguishing it from siblings like pipeline_metrics or source_effectiveness. It explicitly defines the scope as analyzing hired applications to compute specific statistics (average, median, min, max days from application to hire).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with concrete examples ('when asked "how long does it take to hire?" or "what's our average days-to-offer?"'). It also clarifies the scope decision point: 'Pass job_id for a specific role or omit for org-wide metrics,' which helps the agent choose between this tool and potential alternatives for different granularities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly indicates this is a mutation tool ('advance an application'), specifies the required parameters (from_stage_id) and optional behavior (to_stage_id omission leads to sequential advancement). However, it lacks details on permissions, side effects, or error conditions, which are important for a mutation 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 well-structured and front-loaded with the core purpose, followed by usage guidelines and parameter details. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 3 parameters) and the presence of an output schema (which reduces the need to describe return values), the description is mostly complete. It covers purpose, usage, and parameter behavior but lacks details on authentication, error handling, or side effects, which are notable gaps for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of from_stage_id ('the candidate's current stage') and to_stage_id (if omitted, 'advances to the next sequential stage'), adding meaningful context beyond the schema's basic types. However, it doesn't clarify the semantics of application_id or provide examples of valid stage IDs.
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 clearly states the specific action ('advance'), resource ('application'), and scope ('to the NEXT stage in the pipeline (within the same job)'), with concrete examples like 'from "Phone Screen" to "Onsite"'. It effectively distinguishes this tool from its siblings (move_application_same_job and move_application) by specifying its sequential advancement purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (e.g., 'to move a candidate forward one step'), when not to use it (e.g., for moving between arbitrary stages or different jobs), and names specific alternatives (move_application_same_job and move_application). This helps the agent correctly select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key behavioral traits: the tool processes applications sequentially with rate-limit delays (important for performance expectations) and returns success/failure counts (clarifying output behavior). However, it doesn't mention potential side effects like notifications or audit trails, leaving some 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 efficiently structured with four sentences that each earn their place: purpose statement, usage example, safety feature explanation, and behavioral details. It's front-loaded with the core functionality and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature (advancing applications) with no annotations but an output schema, the description provides good coverage of purpose, usage, and key behaviors. It mentions the output format (success/failure counts), which aligns with having an output schema. However, for a batch mutation tool, it could better address error handling or permission requirements.
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?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'application_ids' is described as 'multiple applications' for batch advancement, and 'from_stage_id' is explained as an optional safety check to filter candidates by current stage. This adds meaningful context beyond the bare schema, though it doesn't specify format details like integer ranges.
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 clearly states the tool's purpose with a specific verb ('advance') and resource ('multiple applications'), distinguishing it from the sibling tool 'advance_application' which handles single applications. It explicitly mentions moving candidates to the next stage in batch mode, making the scope and differentiation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('to move a batch of candidates forward — e.g., all candidates who passed a phone screen') and includes a safety check option ('Optionally specify from_stage_id to only advance candidates currently in that specific stage'). It distinguishes from the single-application alternative by emphasizing batch processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key behaviors: pagination behavior ('Default returns one page of 500'), auto-fetch capability ('Set paginate="all" to auto-fetch every page'), and available filters. However, it doesn't mention potential rate limits, error conditions, or authentication requirements, which would be helpful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero waste. It opens with the core purpose, immediately provides key usage information about pagination, lists available filters, and concludes with clear sibling tool alternatives. Every sentence serves a distinct purpose, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, but has output schema), the description is quite complete. It covers purpose, usage guidelines, pagination behavior, and filter options. The existence of an output schema means the description doesn't need to explain return values. However, for a tool with this many parameters and no annotations, mentioning authentication or rate limits would make it more complete.
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?
With 0% schema description coverage for 9 parameters, the description must compensate. It successfully explains the purpose of the 'paginate' parameter, lists available filter types (job_id, candidate_id, status, date ranges), and provides status enum values ('active'/'rejected'/'hired'). While it doesn't cover all 9 parameters individually, it adds substantial semantic value beyond the bare schema.
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 clearly states the tool's purpose as 'List applications with optional filters,' specifying both the verb ('List') and resource ('applications'). It distinguishes from siblings by explicitly naming three alternative tools (pipeline_summary, stale_applications/candidates_needing_action, pipeline_metrics) for different use cases, showing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It states 'For pipeline views with candidates grouped by stage, use pipeline_summary instead. For finding stale candidates, use stale_applications or candidates_needing_action. For conversion rates and hire metrics, use pipeline_metrics.' This gives clear context for when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key behaviors: pagination defaults ('Default returns one page of 500'), auto-fetch capability ('Use paginate="all" to get the complete dataset automatically'), and filter types (email exact, candidate_ids list, date ranges). It doesn't mention rate limits, authentication needs, or error behaviors, but covers the core operational behavior well.
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 efficiently structured with zero waste. The first sentence states the core purpose, followed by pagination guidance, filter details, and sibling tool alternatives. Each sentence adds distinct value: purpose statement, pagination behavior, filter specifications, and usage boundaries. The information is front-loaded 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, but with output schema), the description provides good coverage. It explains the core functionality, pagination behavior, filter types, and sibling tool boundaries. The output schema existence means return values don't need explanation. The main gap is not covering all 9 parameters individually, but the description compensates well for the 0% schema coverage with filter semantics and pagination guidance.
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?
With 0% schema description coverage for 9 parameters, the description must compensate. It adds significant value by explaining filter semantics: 'Filters: email (exact), candidate_ids (list), created/updated date ranges (ISO).' It also clarifies the paginate parameter's special value 'all' for auto-fetching. While it doesn't cover all 9 parameters explicitly, it provides crucial context for the most important ones.
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 clearly states the tool's purpose: 'List candidates with optional filters.' It specifies the resource (candidates) and action (list) with filtering capabilities. It distinguishes from siblings by explicitly naming alternatives for name search (search_candidates_by_name) and resume reading (read_candidate_resume), showing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It states 'For name search, use search_candidates_by_name instead' and 'For reading a candidate's resume, use read_candidate_resume.' It also provides guidance on pagination behavior ('Set paginate="all" to auto-fetch every page'), giving clear 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.
Behavior4/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 effectively describes key behaviors: pagination mechanics ('Fetches candidates in pages'), filtering approach ('filters client-side'), and result limitations ('Returns up to max_pages * per_page candidates scanned'). It doesn't mention error conditions or rate limits, but covers the essential operational behavior well.
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 efficiently structured: purpose statement first, usage guidance second, implementation details third, and example last. Every sentence adds value with zero waste. The example is concise yet illustrative of the substring matching behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (client-side filtering workaround) and the presence of an output schema (which handles return values), the description is quite complete. It explains the workaround nature, pagination approach, and result limitations. It could mention performance implications of scanning many pages, but covers the essential context well for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well. It explains the 'name' parameter's purpose and provides an example. While it doesn't explicitly detail 'per_page' and 'max_pages', their roles are implied in the pagination context ('max_pages * per_page candidates scanned'). The description adds significant value beyond the bare schema.
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 clearly states the specific action ('Search candidates by first or last name') and resource ('candidates'), with details about the matching behavior ('case-insensitive substring match'). It distinguishes from siblings like 'list_candidates' by specifying name-based search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with concrete examples ('when a recruiter says "pull up John's application" or "find Sarah Chen"'). It also explains the technical context ('filters client-side since the Greenhouse API doesn't support name search directly'), giving clear when-to-use reasoning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key traits: it's a read operation (implied by 'List'), includes default behavior ('Default threshold is 14 days'), specifies sorting ('sorted by days since last activity'), and outlines the return format ('with candidate name, current stage, and job name'). However, it doesn't mention pagination or rate limits, leaving some 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 front-loaded with the core purpose in the first sentence, followed by usage context, defaults, filtering details, return format, and next steps. Every sentence earns its place with no wasted words, making it highly efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has an output schema), the description is largely complete. It covers purpose, usage, parameters, and return values adequately. The output schema likely details the return structure, so the description doesn't need to exhaustively explain outputs, but it could briefly mention pagination or error handling for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of 'days' ('no activity for N days'), 'job_id' ('filter to one job'), and implies 'limit' through context (though not explicitly). The description adds significant value beyond the bare schema, clarifying the purpose and usage of each parameter, though it doesn't detail all three explicitly.
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 clearly states the specific action ('List applications with no activity for N days') and resource ('applications'), distinguishing it from siblings like 'list_applications' by focusing on stale candidates. It also specifies the sorting order ('sorted by stalest first'), making the purpose explicit and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('for pipeline hygiene — find candidates that have been sitting untouched') and when not to use it (implied: for general application listing, use other tools). It also names an alternative action ('Use bulk_reject to act on the results'), clearly linking to a sibling tool for follow-up operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: sequential processing, rate-limit delays to avoid Greenhouse's 50 req/10s limit, and that it returns a summary of successes and failures. This covers execution method, constraints, and output format adequately for a bulk 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 front-loaded with the core purpose, followed by usage guidelines, parameter explanation, and behavioral details. Every sentence adds value with zero waste, and it's structured logically from general to specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk mutation with rate limits), no annotations, 0% schema coverage, but with an output schema, the description is complete. It covers purpose, usage, parameters, behavior, and output summary, providing all necessary context for safe and 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?
Schema description coverage is 0%, so the description must compensate. It explains all three parameters: 'application_ids' (list of IDs to reject), 'rejection_reason_id' (optional, from list_rejection_reasons), and 'rejection_email' (optional boolean to send email). This adds meaningful context beyond the bare schema, though it doesn't detail parameter formats or constraints.
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 clearly states the verb ('reject') and resource ('multiple applications') with specific scope ('in one call'), distinguishing it from the sibling 'reject_application' which handles single rejections. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use for 'pipeline hygiene' with 'stale candidates after reviewing the output of stale_applications.' It names a specific sibling tool ('stale_applications') as a precursor and provides a concrete example scenario ('bulk-reject 30 stale candidates').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes what the tool computes (conversion rates, stage metrics, time averages) and the return format (stage-by-stage breakdown with counts, percentages, time metrics), though it doesn't mention potential limitations like data freshness or error conditions.
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 well-structured and front-loaded with the core purpose, followed by usage scenarios, computed metrics, and benefits. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's analytical nature, single parameter, and the presence of an output schema, the description provides complete context. It explains what metrics are calculated, when to use it, and the return structure, leaving no significant gaps for agent 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% description coverage, but the description compensates by implicitly clarifying that 'job_id' refers to the job for which pipeline metrics are computed. However, it doesn't specify format constraints or valid ranges for the job_id parameter.
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 clearly states the specific action ('Compute pipeline conversion rates and stage metrics') and resource ('for a job'), distinguishing it from sibling tools like 'pipeline_summary' or 'time_to_hire' by focusing on detailed stage-by-stage analysis rather than overall summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided with concrete examples of when to use this tool ('when a recruiter asks "what are our conversion rates?" or "where are we losing candidates?"'), and it distinguishes itself from alternatives by stating 'One call instead of assembling data from multiple endpoints.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes what the tool returns (job info, stages with counts, per-candidate details) and its efficiency benefit (replaces 5-10 API calls). However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, leaving some behavioral aspects uncovered.
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 efficiently structured with front-loaded purpose, clear usage guidelines, and return details. Every sentence adds value: the first states what it does, the second when to use it, the third describes returns and efficiency, and the fourth elaborates on return structure. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (aggregating pipeline data), the description is complete enough. With no annotations, it fully explains purpose, usage, and returns. The existence of an output schema means the description doesn't need to detail return values exhaustively, and it appropriately focuses on the high-level structure and benefits.
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% description coverage, but the description compensates by clearly explaining that the single parameter 'job_id' is used to get the pipeline view for a specific job. While it doesn't provide format details beyond what the schema indicates (integer type), it adds meaningful context about what the parameter represents in the tool's operation.
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 clearly states the tool's purpose with specific verbs ('Get a complete pipeline view') and resources ('for a job — candidates grouped by stage'). It distinguishes from siblings by emphasizing a comprehensive view that replaces multiple API calls, unlike simpler list or get tools in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool with concrete examples ('when a recruiter asks "show me the pipeline" or "how many candidates are in each stage for job X"'). It also implies an alternative approach (5-10 sequential API calls) that this tool replaces, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it explains the multi-step behavior (fetches candidate record, finds most recent resume, downloads it), discloses the return format (base64-encoded for binary files, plain text for text files plus metadata), and mentions it's for screening purposes. It doesn't mention potential errors or authentication requirements, keeping it from a perfect score.
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?
Perfectly front-loaded with the core purpose in the first sentence. Each subsequent sentence adds essential value: usage context, behavioral details, and a concrete example. Zero wasted words, well-structured in logical flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations but an output schema, the description is complete: it explains purpose, usage, behavior, return format, and provides an example. The output schema will handle return structure details, so the description appropriately focuses on higher-level semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (parameter 'candidate_id' has no description in schema), but the description compensates by clearly explaining what the parameter represents ('a candidate's most recent resume') and providing context through the example. It doesn't specify format constraints (e.g., integer ID), but the meaning is well-established.
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 clearly states the specific action ('Download and return'), resource ('candidate's most recent resume/CV content'), and scope ('most recent'). It distinguishes from siblings like 'download_attachment' by focusing specifically on resumes for candidates, not general attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use this when screening a candidate') and provides a concrete example scenario. It also implies this is the first step in a workflow ('call this first to get the resume content, then analyze it'), giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 does well by explaining what the tool identifies (applications with no activity, interviews without scorecards, candidates stuck in early stages), default behavior (stale_days default: 7), and output format (categorized action items sorted by urgency). However, it doesn't mention potential side effects, rate limits, or authentication requirements, which keeps it from a perfect score.
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 well-structured and front-loaded with the core purpose. Every sentence adds value: the first states what it finds, the second gives usage examples, the third details what it identifies, the fourth explains parameters, and the fifth describes the return format. There's no wasted text, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 0% schema coverage, no annotations, but an output schema, the description is complete. It covers purpose, usage, parameters, and output behavior. The presence of an output schema means the description doesn't need to detail return values, and it adequately addresses all other aspects given the tool's complexity and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given that schema description coverage is 0%, the description must fully compensate, which it does excellently. It explains both parameters: 'job_id to filter to a specific job, or omit for all active applications' and 'stale_days controls the threshold (default: 7 days without activity = stale).' This adds crucial meaning beyond the bare schema, making parameters understandable and actionable.
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 clearly states the tool's purpose with specific verbs and resources: 'Find candidates that need attention — stale applications, missing scorecards.' It explicitly distinguishes this from sibling tools by focusing on action items rather than general listing or retrieval operations, making it easy to understand its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'Use this when a recruiter asks "what needs my attention?" or "who's been sitting too long?"' It also clarifies when to omit parameters: 'Pass job_id to filter to a specific job, or omit for all active applications.' This gives clear guidance on when and how to use the tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![open-greenhouse-mcp MCP server](https://glama.ai/mcp/servers/benmonopoli/open-greenhouse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/benmonopoli/open-greenhouse-mcp)

Score Badge

Copy to your README.md:

[![open-greenhouse-mcp MCP server](https://glama.ai/mcp/servers/benmonopoli/open-greenhouse-mcp/badges/score.svg)](https://glama.ai/mcp/servers/benmonopoli/open-greenhouse-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/benmonopoli/open-greenhouse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server