100Hires MCP Server

Official

by 100Hires

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation2/5
With 130 tools, many operations overlap or are near-duplicates (e.g., `hires_list_workflow_stages` and `hires_get_workflow_stages` are effectively the same). Batch and single-item variants like `hires_add_candidate_tags` vs `hires_batch_add_tags` add to the confusion, making it easy for an agent to misselect.
Naming Consistency3/5
The `hires_` prefix and mostly verb_noun pattern provide a consistent base, but there are notable deviations: `hires_batch_job_boards` lacks a verb, `hires_get_workflow_stages` duplicates `hires_list_workflow_stages`, and `hires_remove_from_job_board` vs `hires_batch_remove_from_boards` use inconsistent phrasing. Overall still readable, but unpredictable.
Tool Count1/5
130 tools is an extreme count, far exceeding even the 'heavy' threshold. Many taxonomy list tools (origins, sources, rejection_reasons, departments, etc.) could be consolidated into a single taxonomy endpoint. The bloat makes tool discovery and agent selection unnecessarily difficult.
Completeness4/5
The tool surface covers nearly every aspect of an ATS: candidates, applications, jobs, interviews, notes, forms, questions, email templates, nurture campaigns, webhooks, users, companies, and career-site functionality. Minor gaps exist (e.g., no update/cancel interview, no delete for some entities), but the lifecycle is thoroughly represented.
Average 3.9/5 across 104 of 130 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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.
Add a glama.json file to provide metadata about your server.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Remove a specific tag from a candidate' without mentioning permanence, idempotency, prerequisites (e.g., tag must exist), or any side effects, which is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words, making it front-loaded and easy to parse. It is concise, though it omits important context, which limits the score slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is under-specified. It does not explain the operation's effects (e.g., whether removal is permanent), error handling, or how it differs from batch removal. The schema covers parameters well, but contextual completeness remains low.
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 fully documents both parameters (id and tag) with descriptions, achieving 100% schema coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the object (a specific tag), and the target (a candidate), making the tool's purpose distinct from add/list operations. However, it does not explicitly differentiate from sibling hires_batch_remove_tags, relying on the word 'specific' to imply singular use.
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 choose this tool over alternatives like hires_add_candidate_tags or hires_batch_remove_tags. The description only states the operation without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the action. It does not disclose whether deletion is permanent, whether associated questions or data are affected, or any permissions required. With no annotations, 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 single-sentence description is extremely concise and immediately communicates the tool's function. 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?
For a simple delete operation, the description is minimal but lacks context about the resource type and its distinction from related entities. It does not clarify the difference between 'application form' and the 'application' resource present in sibling tools, leaving potential ambiguity.
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 already documents the 'id' parameter as 'Form ID' with full coverage. The description adds no additional semantics or formatting details, so it provides no value beyond the 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 action (delete) and the resource (application form), making the tool's purpose unambiguous. It distinguishes from sibling tools like hires_delete_application by targeting the form entity specifically.
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?
There is no guidance on when to use this tool versus alternatives, such as when to delete an application form versus an application or when deletion is appropriate. No mention of prerequisites or context.
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, the description carries the burden of disclosing behavior. It reveals an access constraint (company must be own or client) and clarifies the scope (all users in the company). However, it does not mention pagination, error handling, or what happens if the company is not accessible, which would be valuable for a list 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, clear sentence that is front-loaded with the primary action. No wasted words, and it includes a critical constraint without verbosity.
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 is a simple list operation with three parameters and no output schema. The description provides essential context (company accessibility and scope) but lacks details about response format, pagination behavior, or error cases. Given the sibling ambiguity, a bit more context would improve completeness, but it meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the 'id' parameter being a company that must be accessible, but this is marginal. It does not explain the 'page' or 'size' parameters beyond the schema, which is acceptable since the schema already covers them.
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 lists all mail accounts for all users in a specific company, which is a specific verb and resource. However, it does not explicitly differentiate from the similarly named sibling tool 'hires_list_company_mail_accounts', so it misses some 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 a prerequisite (company must be accessible) but gives no explicit guidance on when to use this tool versus alternatives like 'hires_list_user_mail_accounts' or 'hires_list_company_mail_accounts'. No 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?
In the absence of annotations, the description carries the full burden of behavioral disclosure. It only states the action and target fields, but does not describe whether the 'questions' array replaces the existing set, whether the update is partial or full, or any side effects or permission requirements. This leaves important behavioral traits undisclosed.
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, concise sentence that directly states the tool's purpose. It is front-loaded and contains no fluff, making it 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?
The tool is relatively simple and the schema covers all parameter descriptions. However, the description does not clarify update semantics (e.g., whether questions is a full replacement), nor does it mention the required 'name' field explicitly. There is no output schema, so the return value is unspecified, but that is not unusual. Overall, the description is minimally adequate but lacks key behavioral details.
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 already provides descriptions for all three parameters (id, name, questions) with 100% coverage, so the baseline is 3. The description adds minimal extra meaning by calling 'questions' 'question composition', but this does not explain semantics like array replacement behavior. It does not compensate or add beyond the 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 uses the verb 'update' with the resource 'form' and specifies the exact aspects: name and question composition. This distinguishes it from sibling tools like hires_update_form_question, which updates a specific question, and hires_update_question, which updates question content. It effectively communicates the tool's 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 explicit guidance on when to use this tool versus alternatives. It does not mention when to use hires_update_form_question or hires_update_question, nor does it specify prerequisites or intended scenarios. The only implicit guidance comes from the tool name and the generic description.
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?
The description discloses it returns file metadata and download URLs, providing some insight into the response behavior. However, there is no mention of error handling, authorization, pagination, or limits, and no annotations are provided to compensate.
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 concise and front-loaded with the core purpose, followed by a brief explanation of the return value. Two short sentences with no unnecessary detail make it efficient 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?
For a simple tool with one parameter and no output schema, the description covers what the tool does and what it returns. It lacks usage guidance or reference to related tools, but the essential information is present and sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single 'id' parameter as 'Application ID.' The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all file attachments linked to an application, with examples of attachment types (resumes, cover letters, documents) and specifies the return value (file metadata and download URLs). It distinguishes itself from siblings like download tools by indicating it lists metadata, but it does not explicitly contrast with similar list tools such as hires_list_candidate_files.
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 given on when to use this tool versus alternatives. The description lacks any mention of prerequisites or when to prefer this over similar tools like hires_download_attachment for retrieving files.
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 the main effect (stops listing on specified boards) but omits details such as reversibility, permissions, error conditions, or what happens if the boards parameter is omitted. This is a significant gap 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 two concise sentences, front-loaded with the action, and contains no redundant information. Every word contributes to clarity.
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?
Despite the tool's simplicity, the description leaves important gaps: the boards parameter is optional in the schema, but the description does not clarify what happens when it is omitted. No mention of response or side effects, and with no output schema, the description should provide more context 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 coverage for parameters is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions; it merely maps 'selected board publications' to the boards parameter and 'for a job' to id, which the schema already conveys.
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 action: deactivating selected board publications for a job, which stops the job from being listed on specified boards. The verb 'deactivate' and resource 'board publications' make the purpose unambiguous and distinguish it from related tools like publish or 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 for a single job with selected boards, but it does not explicitly state when to prefer this tool over alternatives like batch removal or publishing, nor does it mention exclusions. Usage context is implied rather than explicitly guided.
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 updating fields and CV but does not disclose side effects, partial vs full update behavior, permissions, or response format. 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 two sentences, front-loaded with the action and followed by the use case. Every word earns its place; no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, nested objects, no output schema), the description is too sparse. It omits update semantics, return values, and potential error conditions. The sync context is helpful but incomplete.
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?
All 9 parameters are fully described in the schema (100% coverage), so the description adds little beyond grouping them into 'fields, profile answers, and optional CV.' The schema already explains each parameter's meaning and 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 tool updates candidate fields, profile answers, and optional CV, which is a specific verb+resource combination. It distinguishes from read, create, and delete tools, but does not explicitly differentiate from other update tools like update_application.
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 explicitly mentions the tool is 'Used for bi-directional sync from ATS, CRM, sourcing, or enrichment tools,' providing a clear use case. It does not name alternatives or exclusions, but the integration context is clear enough.
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 does not disclose whether the update is partial or full, what permissions are required, or any side effects. The phrase 'Supports partner-operated account management' is vague and does not clarify the tool's behavior, such as whether it overwrites existing owner data or only updates provided fields. This is a significant gap 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 extremely concise, consisting of two short sentences. It front-loads the core purpose ('Update company profile...') and adds a brief context note. There is no wasted wording, and every phrase contributes to understanding the tool's function and special capability.
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?
With 9 parameters, a nested object for the logo, no output schema, and no annotations, the description is too incomplete. It does not specify what the tool returns (e.g., whether it returns the updated company object or a success message), how partial updates are handled, or what 'partner-operated account management' entails. The tool's complexity demands more context than this minimal description provides.
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 descriptions cover 100% of the parameters, each with clear definitions, so the baseline is 3. The description adds some semantic grouping by mentioning 'owner contact data' and 'optional logo', which helps relate the parameters to the overall purpose, but it does not provide any additional syntax or format details beyond the schema. The added value is marginal but present.
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: 'Update company profile, owner contact data, and optional logo.' This specifies the verb (update), the resource (company), and the scope (profile, owner data, logo). It also distinguishes itself from sibling tools like create_company, get_company, delete_company, and restore_company by focusing on updates. The mention of 'partner-operated account management' adds a distinct use case.
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 ('Update company profile...') but does not explicitly state when to use this tool over alternatives. The phrase 'Supports partner-operated account management' hints at a specific context, but it does not provide exclusions or name alternative tools, unlike a fully guided description. The usage is implied from the resource being 'company', which is unique among update tools, but no explicit guidance is given.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. As a mutation tool, it does not state prerequisites (e.g., that the form and question must exist), potential side effects (e.g., whether hiding a question affects existing responses), or what the API returns on success or failure. The description only identifies the action without consequences.
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 sentence that immediately states the action and target, with no unnecessary words. It effectively serves as a clear, front-loaded summary.
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 absence of annotations and output schema, the description needs to explain return values, error conditions, and intended usage scenarios. It lacks all of these, leaving the agent uncertain about what to expect when invoking the tool. For a tool with three parameters and a mutating action, this is a significant gap.
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 already covers all parameters with descriptions, including the enum for status. The description adds no additional parameter syntax or format details beyond what the schema provides. It merely restates the purpose of the parameters in a general way, so the baseline of 3 is appropriate.
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 uses the verb 'Update' with a specific resource: 'status (required/optional/hidden) of a question inside a form.' This clearly differentiates from sibling tools like hires_update_question (which updates question details) and hires_update_form (which updates form-level settings). The scope is precise: it only concerns the status of a question within a specific form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for changing question status (required/optional/hidden) in a form, but provides no explicit guidance on when to use it versus alternatives. There is no mention of situations where one would prefer hires_update_question or hires_update_form. The usage context is inferable from the resource scope, 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 the full burden of behavioral disclosure. It mentions base64 encoding, which is useful, but omits critical behavioral details like whether this is a write operation with side effects, required permissions, size limits, or what happens on success or failure. This is insufficient for an upload tool without 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 two sentences, immediately front-loaded with the core action, and every sentence earns its place. The base64 reminder is redundant with the schema but still useful as a quick reference, and the use-case note adds context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a nested file object, the description is too sparse. It does not cover expected response, error cases, permissions, or potential side effects like replacing existing attachments. A more complete description would address these gaps to help agents use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all parameters including nested file properties. The description adds no significant new parameter semantics beyond restating that data must be base64-encoded, which is already in the schema, so the baseline of 3 applies.
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 uploads a file attachment to an application, with a specific verb and resource. It distinguishes itself from sibling tools like hires_upload_candidate_file by explicitly targeting applications, and the use cases (signed documents, interviewer artifacts) add concrete context.
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 application-level attachments and mentions common scenarios, but it does not explicitly state when to choose this tool over alternatives such as hires_upload_candidate_file or hires_upload_attachment, nor does it provide exclusion criteria or prerequisites.
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 carry the full burden. It only says 'Create a client company and link ownership context' without disclosing permissions, idempotency, side effects, or response behavior. For a mutation tool, 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, front-loaded sentence that concisely states the core action and context without unnecessary words. It is well-structured and every word contributes value.
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 8 parameters, a nested logo object, no output schema, and no annotations. While the schema documents all parameters, the description does not explain return values or special behaviors. The high-level purpose is clear, but missing details like response format or constraints make it only minimally 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?
The input schema fully covers all 8 parameters with descriptions, achieving 100% coverage. The description adds no additional parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a client company' with a specific verb and resource, and adds 'link ownership context' to distinguish it from other company-related tools. It is unambiguous and differentiates from siblings like hires_list_companies, hires_update_company, and hires_delete_company.
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 phrase 'Typical entrypoint for multi-tenant onboarding' provides context for when to use the tool, implying it is for new client creation. However, it does not explicitly mention alternatives or when not to use it, so guidance is implied rather than explicit.
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 disclosing behavior. It only states 'List' which implies a read-only operation, but it does not describe the return format, pagination behavior, or any potential side effects. There is no mention of what 'history' includes or any 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 two sentences long, front-loaded with the core action, and every word earns its place. It is concise and effectively 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?
This is a simple list operation with four parameters and no output schema. The description covers the primary purpose but omits details about return values, pagination behavior, and any preconditions. It is adequate but lacks the richness needed for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The description's mention of is_scheduled=1 is redundant with the schema. It does not add meaningful semantics beyond what the schema already provides.
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 function: 'List email and messaging history for a candidate.' It uses a specific verb and resource, and the phrase 'for a candidate' distinguishes it from broader message-listing tools like hires_list_messages.
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 a specific usage tip for the is_scheduled parameter, but it does not explain when to use this tool versus alternatives or state any exclusions. The intended use case is implied by the tool's name and the 'for a candidate' phrasing, but no explicit guidance is given.
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. It states 'paginated' which indicates a behavioral trait, but this is already evident from the page and size parameters in the schema. It does not disclose read-only nature, response format, or any other behavioral details. The description adds minimal value beyond the verb 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence with no wasted words. It includes the essential verb, resource, and a key qualifier ('paginated'). Perfectly concise for the tool's simplicity.
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 no output schema, the description provides the minimum viable context: it lists questions, supports pagination, and scopes to a company. However, it leaves ambiguity about what 'question catalog' includes (e.g., active vs. all questions, sorting, response fields). Given the many sibling list tools and no annotations, a bit more detail would improve completeness, but the current state is 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 100%, with all three parameters (page, size, company_id) documented in the schema. The description adds no extra meaning to parameters, but the baseline of 3 applies because the schema fully documents them. The phrase 'for the company' mildly reinforces the company_id parameter but does not add new semantic content.
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 uses a specific verb 'List' and clearly identifies the resource as 'question catalog for the company.' It distinguishes itself from sibling list tools by explicitly targeting questions, and from the related 'hires_list_question_types' by focusing on the catalog rather than types. Purpose is unmistakable.
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: use this tool when you need to list paginated questions for a company. However, it provides no explicit guidance on when to choose this over alternatives like 'hires_list_question_types' or other list tools. There are no exclusions or mention of alternative tools, leaving the usage context only implicitly 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 responsibility for behavioral disclosure. It mentions filtering by workflow or job, but does not explain default behavior when no filters are given, required permissions, or what the returned stages include (e.g., IDs, names, ordering).
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, using two short sentences that front-load the main action and then provide a useful context sentence. No wasted words.
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 there is no output schema and no annotations, the description should explain what is returned. It says 'List pipeline stages,' which is somewhat informative, but lacks details about default behavior, result structure, or edge cases. Still, for a simple list tool, it is marginal but not wholly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema describes each parameter. The description's mention of 'filtered by workflow or job' adds little beyond what the schema already states, so it meets the baseline without significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pipeline stages and can filter by workflow or job. It uses a specific verb ('List') and identifies the resource, though it does not explicitly distinguish from the sibling tool 'hires_get_workflow_stages'.
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?
Provides clear context: 'Useful for transition UIs and workflow validation.' This gives an idea of when to use it, but does not mention alternatives or when not to use it, so no exclusions 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 the full burden of behavioral disclosure. It only restates the action without revealing consequences like mutating job-board associations, what happens when the optional 'boards' parameter is omitted, or whether the operation is reversible. This is a significant gap 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 two sentences, both purposeful. The first sentence states the core functionality, and the second provides usage guidance. No redundant or filler content.
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?
This is a mutation tool with no output schema and no annotations. The description does not cover what happens on partial failure, the meaning of an empty boards array, or return values. The presence of related sibling tools (e.g., batch_publish_to_boards) helps but does not make the description complete. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'jobs' and 'boards' have descriptive comments. The description does not add meaning beyond the schema; it just implies the endpoint's purpose. The baseline of 3 applies because the schema already documents parameters clearly.
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 action: 'Deactivate board publication for multiple jobs in one request.' This is a specific verb-resource pairing that distinguishes it from singular alternatives like hires_remove_from_job_board and the inverse bulk operation hires_batch_publish_to_boards.
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 explicitly says 'Use for bulk depublishing workflows,' which provides clear context for when to use the tool. However, it does not explicitly name alternatives or state when not to use it, such as for single-job depublishing.
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, but it only mentions the action and scope. It fails to disclose important side effects such as automatic creation of a default form or workflow when form_id or workflow_id are omitted, or whether the job is published immediately based on status. This is a significant gap for a create tool with 28 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 three concise sentences, front-loaded with the primary action. It avoids redundancy and fluff, with each sentence contributing either purpose, usage context, or essential required-field information. This is appropriately sized for a 28-parameter tool.
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 (28 parameters, no output schema, no annotations), the description is insufficient. It does not explain return values, side effects like default form/workflow creation, or how status affects publishing. The schema describes parameters but cannot compensate for missing high-level behavioral and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 28 parameters are documented. The description adds only high-level grouping ('taxonomy, location, salary, and workflow configuration') and repeats required fields, which is already in the schema. It does not add meaningful detail beyond the schema, warranting the baseline score of 3.
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 function: 'Create a job' with taxonomy, location, salary, and workflow configuration. It also positions it as the 'Primary endpoint for programmatic job publishing,' distinguishing it from siblings like hires_update_job, hires_delete_job, and hires_set_job_status.
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: 'Primary endpoint for programmatic job publishing.' It implies this is the go-to creation tool for jobs, but it does not explicitly mention alternatives or when-not-to-use scenarios, such as 'use hires_update_job to modify an existing job.'
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 a key constraint ('URL must be HTTPS') and indicates this is a setup step, but does not mention side effects, authentication requirements, or what response to expect. The description adds some value beyond the schema but lacks rich 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 two sentences, front-loaded with the primary action, and every phrase earns its place. The extra note 'Core step for outbound integration setup' adds context without verbosity, and 'URL must be HTTPS' is a critical constraint stated concisely.
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 simple two-parameter create operation, the description provides the basic action but omits expected response behavior (no output schema exists). It also fails to differentiate from the similar sibling 'hires_create_webhook', leaving the agent uncertain about which to choose. This is a notable gap for 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 schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The tool description repeats the HTTPS requirement already present in the schema, offering no additional semantic value. It does not clarify the exact format of 'alias' or how the job ID maps to 'job-related events'.
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 ('Register a webhook URL') and the resource ('job-related events'), using a specific verb and object. However, it does not distinguish this tool from the sibling 'hires_create_webhook', which likely serves a different scope (general vs job-specific webhooks). The phrase 'job-related' provides some differentiation, but the ambiguity remains.
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 phrase 'Core step for outbound integration setup' gives clear context on when to use this tool, implying it's needed for outbound integrations. It does not explicitly mention alternatives or provide exclusion criteria, but the context is sufficiently clear.
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, the description carries the full burden of behavioral disclosure. It adds useful context by stating that steps are executed sequentially and listing the allowed step types with type-specific fields. However, it does not disclose what happens upon creation (e.g., return value, whether the campaign is active immediately), permissions required, or any side effects, leaving 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 two sentences, front-loaded with the core purpose. Every phrase earns its place: it names the operation, describes the steps, and notes the optional workflow binding—all without repeating schema details or adding filler.
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?
This is a complex tool with 11 parameters, no annotations, and no output schema, so the description must compensate. It fails to mention what the tool returns, how the campaign is triggered, or any default behaviors (e.g., `send_to_all`). The description is a minimal summary that leaves many operational questions unanswered for an agent to invoke the tool reliably.
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?
Although the schema description coverage is 100%, the description adds meaning beyond the structured fields. It explicitly enumerates the six step types, highlighting the polymorphic structure of the steps array, and clarifies that steps run sequentially—information not directly evident from the JSON schema. It also mentions optional workflow binding, which helps interpret the `workflow_id` and `stage_id` parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create a nurture campaign with steps,' which clearly states the primary action and resource. It distinguishes the tool from sibling create/update/delete/list operations for nurture campaigns, and the mention of 'bind to a workflow stage' adds relevant scope without 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 explicit guidance on when to use this tool versus alternatives. It does not mention that this is for creating new campaigns while update is for modifying existing ones, nor does it suggest any prerequisites or scenarios where this tool is appropriate. Usage is only implied by the verb 'create'.
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, the description must disclose behavioral traits. It states that it deletes a company but does not reveal side effects, whether deletion is reversible, permission requirements, or impact on related data. The existence of a 'restore_company' sibling is not referenced, leaving uncertainty about whether this is a soft or hard delete.
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?
Two short sentences front-load the core action and then add context. No unnecessary words—very 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 operation, the description is too thin. It lacks details about consequences, reversibility, or return behavior. Even though the tool is simple, the absence of behavioral information leaves the agent uncertain about the operation's impact.
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 already fully covers the only parameter, 'id' (described as 'Company ID'), so the description adds no additional parameter semantics. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Delete a company.' The verb and resource are specific, and the phrase 'lifecycle control in partner tenancy management' provides domain context, distinguishing it from sibling company tools (create/get/update/restore).
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 says 'Use for lifecycle control in partner tenancy management,' which indicates a clear use case. However, it does not mention alternatives or exclusions, such as contrast with hires_restore_company, so there is room for more explicit when-not-to-use guidance.
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. However, it only states the retrieval action ('Get') and does not disclose potential side effects, permissions, rate limits, or details about the return structure beyond the high-level mention of application summaries. It is a read operation, but this is not explicitly stated.
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, compact sentence that front-loads the action and resource. Every word adds value, with no redundant phrases or filler. It is appropriately sized for the tool's simplicity.
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 one-parameter retrieval tool with no output schema and no annotations, the description provides sufficient context by naming the resource and indicating that application summaries are included. It does not enumerate all returned fields, but given the tool's simplicity, the high-level description is mostly 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?
The input schema provides 100% description coverage for the single 'id' parameter, including the dual format (integer or alias). The description merely echoes this information ('by candidate ID or alias') without adding further semantic detail, so the baseline of 3 applies.
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 uses a specific verb ('Get') and resource ('full candidate data including application summaries') and clearly identifies the lookup mechanism ('by candidate ID or alias'). This distinguishes it from sibling tools like hires_get_candidate_resume and hires_list_candidates, which serve 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to retrieve a single candidate's full data including application summaries) but does not explicitly mention alternatives or when not to use it. It provides clear context of scope but lacks exclusions or comparative guidance.
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 only states that the tool lists boards with metadata, but does not disclose whether it is read-only, whether special permissions are needed, or what scope of data is returned. This is 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 extremely concise, with two short sentences. The first sentence front-loads the purpose, and the second adds usage context. There is zero redundancy or wasted words.
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 list tool with no output schema, the description is somewhat complete: it covers purpose and usage. However, it fails to specify what 'metadata' is returned, and it does not clarify how this tool relates to similar ones like hires_list_job_boards. Thus, there are clear gaps that could confuse an 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 input schema has zero parameters, so the baseline for this dimension is 4. The description adds no parameter details, but none are needed; it appropriately avoids commenting on nonexistent 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 identifies the tool's function: 'List available publishing boards with metadata.' It specifies a resource (publishing boards) and includes metadata, which differentiates it from generic list tools. However, it does not explicitly distinguish itself from similar siblings like hires_list_job_boards, so it falls just short of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use for distribution setup and board selection.' This tells the agent when to employ the tool. However, it does not mention exclusions or alternative tools, so it lacks full 'when not to use' guidance.
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 only states the core transformation without mentioning side effects, failure modes, prerequisites, or whether the operation is read-only. This is minimal transparency for a tool with no structured safety hints.
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 communicates the core purpose without any superfluous information. It is appropriately sized and front-loaded.
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?
With 6 parameters, no annotations, and no output schema, the description is insufficient. It does not explain which parameter combinations are valid for each placeholder type, nor does it describe the HTML tag format or return value. This leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any detail about how parameters like job_variable_id or system_column_title relate to the placeholder 'type' field, but the schema already provides descriptive names and descriptions for each 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 tool's function: converting a placeholder reference into an HTML tag for email template insertion. The verb 'convert' and the resource 'placeholder reference' are specific, and it distinguishes this from sibling tools like hires_list_template_placeholders (which lists placeholders) and email template CRUD tools.
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 implies the tool is used when needing to insert a placeholder into an email template body, providing clear context. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a full 'when/when-not' guideline.
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 transparently indicates that suppression of the rejection email is possible and implies that by default an email is sent. However, it does not disclose other side effects (e.g., changes to application status, reversibility) or the return value, which is a notable gap 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 two sentences, front-loaded with the primary purpose and then providing two actionable pointers. Every sentence adds value without redundancy or unnecessary filler.
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 core action and key parameter sources, but it does not explain what the tool returns (since there is no output schema) or any prerequisites for rejecting an application. This leaves some gaps for an agent, though the tool is simple and the provided details are helpful.
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?
Although the schema already describes all parameters (100% coverage), the description adds meaningful semantics beyond the schema. It explains that rejection_reason_id must come from GET /taxonomy/rejection-reasons and clarifies that suppress_notification skips the rejection email, which helps the agent correctly select and set these 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 tool's purpose: 'Reject an application' with an optional rejection reason. It is specific about the resource and action, but it does not explicitly distinguish itself from sibling tools like hires_batch_reject_applications or hires_unreject_application, leaving the 'single application' aspect implicit.
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 gives useful context on how to use the optional rejection reason (fetch from GET /taxonomy/rejection-reasons) and how to suppress the default rejection email. However, it does not mention when to prefer this tool over alternatives (e.g., batch rejection) or any exclusions, so usage guidance is implied rather than explicit.
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, the description carries full responsibility. It discloses two important behavioral traits: partial updates (only changed fields are sent) and preservation of domain validation. However, it omits other critical behaviors such as return value, idempotency, permission requirements, or side effects of status changes, which is significant 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 extremely concise—three short sentences that front-load the core purpose and include only high-value behavioral notes. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 28 parameters, no output schema, and no annotations, this description is too sparse. It does not mention what the response looks like, potential error scenarios, or constraints beyond generic validation. While the schema covers individual parameters, the lack of behavioral context leaves the agent uncertain about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 28 parameters, so the schema already provides semantic meaning. The tool description adds only generic guidance ('Only send fields you want to change'), which is not parameter-specific but does reinforce the partial-update semantic.
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 'Update mutable job attributes', which specifies the verb (update) and resource (job). This distinguishes it from create/delete/get sibling tools and indicates a general update operation, while 'Only send fields you want to change' further clarifies the scope.
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 partial-update behavior with 'Only send fields you want to change' and notes validation rules, but it does not explicitly say when to use this tool over alternatives like hires_set_job_status or provide exclusions. Context is present but no direct comparison to 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the basic action but does not mention side effects, idempotency, duplicates, permissions, or return behavior. This is minimal information beyond the function itself.
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 two sentences, front-loaded with the primary action, and the second sentence adds useful use-case context. Every word earns its place with no 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?
For a simple mutation tool with no annotations and no output schema, the description covers purpose and use cases but omits practical details like duplicate tag handling, idempotency, and the relationship to batch_add_tags. It is 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 input schema covers both parameters ('id' and 'tags') with descriptions and full coverage. The description adds the phrase 'one or more tags' which aligns with the array type, but does not add meaningful semantic detail beyond the 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 identifies the action ('Add one or more tags to a candidate') with a specific verb and resource. It also distinguishes this tool from siblings like hires_remove_candidate_tag and hires_list_candidate_tags, and from the batch alternative by targeting a single candidate.
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 gives clear context for when to use this tool ('Used for campaign tagging, qualification labels, and source attribution'). It does not explicitly mention when not to use it or alternatives like hires_batch_add_tags, but the single-candidate scope is implied.
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, the description carries the full burden. It discloses valuable behavioral details: items are processed independently (one failure does not stop others) and per-candidate RBAC is enforced. However, it does not explain side effects (e.g., whether messages are sent immediately or only scheduled), error handling, or return format, which are important 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 three concise sentences, front-loads the core purpose, and avoids redundancy. Every sentence adds useful information, from the batch limit to independence and RBAC.
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 description covers purpose, scale, and key behavioral traits, it is incomplete for a batch mutation tool. It does not describe how results or partial failures are returned, whether messages are sent immediately or scheduled for future delivery, or any rate limits beyond the 100-message cap. Given no output schema or annotations, more detail is needed for full operational clarity.
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 provides 100% description coverage for all properties, so the schema does the heavy lifting. The description adds marginal value by noting that each item specifies its own candidate_id and payload, but this is already evident from the schema. It does not clarify semantics beyond what the schema already states.
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 creates up to 100 scheduled messages in one request, with a specific verb, resource, and scale limit. It distinguishes itself from related sibling tools like hires_send_candidate_message by emphasizing the batch 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 for batch scheduling but does not explicitly mention when to use it versus alternatives like the singular send-candidate-message tool. It provides useful context such as independent processing and per-candidate RBAC, but lacks explicit 'when to use' or 'when not to use' guidance.
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 must disclose behavioral traits. It identifies the operation as an activation (a mutation), but does not mention side effects, required permissions, error behavior, or reversibility. For a batch publish operation, this lack of transparency 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 two short sentences with the primary action front-loaded. There is no redundant wording, making it efficient and scannable.
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 is relatively simple with two well-described parameters and no output schema. The description covers the purpose and use case but leaves ambiguity about the behavior when the optional 'boards' parameter is omitted. It is adequate but not 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 input schema has 100% parameter description coverage, with both 'jobs' and 'boards' clearly described. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('activate board publication'), the object ('multiple jobs'), and the batch nature ('in one request'). It effectively distinguishes itself from single-job publish tools and aligns with bulk distribution workflows.
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 phrase 'Use for bulk job distribution workflows' provides explicit context for when to use this tool. It does not explicitly list alternatives or exclusions, but the batch vs. single connotation is clear from the 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 the full burden of behavioral disclosure. It only states the basic action and optional question attachment, but does not disclose side effects, permissions, reversibility, or error conditions. This is a significant gap 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, front-loaded sentence of 12 words. Every word earns its place, and there is zero fluff or unnecessary 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?
The tool is simple with three parameters and no nested objects. However, since there is no output schema, the description should clarify what the response contains. It also does not explain the role of company_id or prerequisites. The description is minimally viable 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 schema has 100% coverage with clear descriptions for all three parameters. The description adds a minor nuance by specifying 'existing questions by ID' for the questions parameter, but this is already implied in the schema. The description does not need to compensate for missing schema info.
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 uses a specific verb ('Create') and resource ('application form'), and clearly distinguishes from siblings like update_form and delete_form. The optional attachment of questions by ID is a distinct capability that further clarifies its purpose.
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 implies when to use the tool: when creating a new application form, not updating or deleting. It provides clear context but does not explicitly mention alternatives or when not to use it. Given the simplicity of the operation, this is acceptable.
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, the description carries the full burden. It discloses one behavior—location auto-resolution/creation—but does not mention permissions, side effects of scheduling, conflict handling, or response shape. For a create operation this is a meaningful 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?
Two concise sentences, front-loaded with the core purpose and followed by the most important input constraints. No filler or redundant 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?
The description is adequate for basic invocation given the rich schema, but lacks information about prerequisites (e.g., application must exist), potential errors, or response behavior. Since there is no output schema, a bit more context would improve 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?
Schema coverage is 100%, so baseline is 3. The description reinforces that start/end times are Unix timestamps and interviewer_ids is a list, but this largely restates the existing schema descriptions rather than adding new semantics.
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?
Uses a specific verb 'Schedule' and resource 'interview' for an application, clearly distinguishing this creation tool from sibling read tools like hires_list_interviews and hires_get_interview.
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?
Clearly conveys when to use it (to schedule a new interview) and identifies the essential inputs (Unix timestamps and interviewer IDs). It does not explicitly contrast with alternatives, but no alternative create-interview tool exists 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, the description carries the full transparency burden. It discloses visibility control and @mention email notifications, but omits authentication requirements, return value, side effects, or any prerequisite conditions. This is only partial disclosure 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 sentence that front-loads the primary purpose and then mentions two key options. There is no filler or redundant content, 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?
For a create operation with 6 parameters, no output schema, and no annotations, the description covers the main purpose and key features but omits details like return payload, error conditions, or prerequisites. It is adequate but not comprehensive.
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 coverage is 100%, so the baseline is 3. The description adds value by explicitly explaining the visibility and @mention behaviors, reinforcing the semantics of the 'visibility' and 'mention_user_ids' parameters beyond the schema's basic descriptions.
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 'Create' and the resource 'discussion note for a candidate', which is specific and unambiguous. It also highlights distinguishing features (visibility control and @mentions), separating it from sibling note operations like get, update, delete, and list.
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 creating candidate notes, especially when visibility control or @mentions are needed, but it does not explicitly reference alternatives or provide when-not-to-use guidance. Since sibling note CRUD tools exist, explicit differentiation would improve clarity.
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, the description carries the full burden of disclosing behavioral traits. It states the tool creates a reusable question, implying a write operation, but does not disclose permissions, side effects, reversibility, or return behavior. The mention of 'optional answer options for dropdown types' provides some constraint context, but overall transparency is limited.
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 two sentences, front-loaded with the main action, and contains no unnecessary words. 'Create a reusable question with optional answer options for dropdown types. Used by forms and questionnaires.' Every sentence earns its place, 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?
The tool has 4 parameters (2 required), no output schema, and no annotations. The description covers the tool's core purpose and usage context, but does not mention return values, prerequisites, or any potential side effects. Given the lack of annotations, more detail about expected outcomes would improve completeness. It is 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 100%, so the baseline is 3. The description adds only a slight clarification for 'options' ('dropdown types') which is redundant with the schema's 'for select/multiselect question types'. It does not add any new syntax or format details beyond what the schema already provides, so it stays at baseline.
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 uses a specific verb 'Create' and resource 'reusable question' with clear scope ('with optional answer options for dropdown types'). It distinguishes itself from sibling tools like hires_get_question, hires_update_question, and hires_delete_question by clearly indicating it is the creation operation. The additional context 'Used by forms and questionnaires' further clarifies its purpose.
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 usage context: 'Used by forms and questionnaires' implies when to use this tool. It does not explicitly state alternatives or exclusions, but the verb and resource make it obvious this is for creating new reusable questions, not for updating or listing them. This is sufficient for a simple create 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states 'Delete a job' but does not mention whether the operation is reversible, whether it cascades to related records (applications, candidates), or any permission requirements. For a destructive tool, 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 consists of two concise sentences. 'Delete a job' is direct and front-loaded, and the second sentence adds context without unnecessary words. It is appropriately sized for a simple tool with one parameter.
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 delete operation, the description covers the core action and a use case. However, given its destructive nature, it lacks crucial details such as irreversibility, impact on linked entities, and prerequisites. This leaves the description incomplete for informed 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 schema describes the sole parameter 'id' as 'Job ID (numeric) or alias' with 100% coverage. The description adds no extra semantic details about the parameter, but the schema is sufficient, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a job' with a specific verb and resource. This distinguishes it from sibling tools like hires_get_job, hires_update_job, and hires_set_job_status. The additional phrase 'Use to align archived/removed positions...' reinforces the intended scope.
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 a clear use case: 'Use to align archived/removed positions across integrated platforms.' This indicates when the tool is appropriate, though it doesn't explicitly contrast with alternatives like hires_set_job_status or hires_remove_from_job_board. The guidance is adequate but lacks explicit 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 the full burden of behavioral disclosure. It says 'Delete' but does not state whether the deletion is permanent, irreversible, or if any cascading effects occur. For a destructive operation, 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 concise and front-loaded: 'Delete a note.' followed by a short usage phrase. Every word earns its place, with no unnecessary 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?
The tool is simple with one parameter and no output schema, so the description provides basic purpose and usage context. However, it lacks explicit behavioral transparency (e.g., permanence of deletion), which would enhance completeness. It is adequate but not exceptional.
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 sole parameter 'id' is fully described in the schema as 'Note ID', giving 100% schema description coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
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 deletes a note, specifying both the action (delete) and the resource (note). This distinguishes it from other delete tools like hires_delete_application or hires_delete_candidate, and within note-related siblings only this tool deletes notes.
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 usage context: 'Use for moderation policies and data cleanup operations.' It indicates when to use the tool, though it does not explicitly mention alternatives or exclusions. This is sufficient for a straightforward delete 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Delete' and 'Use cautiously,' but does not reveal whether deletion is permanent, what happens to questions used in existing job/forms, required permissions, or the response format. The caution is vague.
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 two short sentences, action-first, with a useful caution in the second sentence. There is no wasted wording.
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 is simple with one parameter, but because it is a mutation with no annotations or output schema, the description should explain consequences for linked entities or whether deletion is reversible. The cautionary note helps a bit but lacks specifics.
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 provides 100% coverage for the single 'id' parameter with 'Question ID.' The description adds no meaningful semantic detail beyond calling the resource a reusable question, which is already implicit in the tool name and 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 opens with 'Delete a reusable question from the catalog,' clearly stating the action (delete) and the resource (reusable question). This clearly distinguishes it from other delete_* siblings by specifying the question/catalog context.
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?
It states that the tool deletes reusable questions and adds a caution about using it when deprecating question banks, providing clear usage context. It does not explicitly name alternatives, but for a simple deletion tool the context is sufficient.
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 burden of behavioral disclosure. It clarifies that `include` can embed workflow, hiring team, or pipeline stages, which adds useful context. However, it does not mention what happens for invalid IDs, the exact return shape, or any authentication/permission requirements, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the primary function and a secondary hint about `include`. Every sentence adds value with no redundancy or filler.
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 get tool with two parameters, the description is adequate but not comprehensive. It mentions the `include` feature, but without an output schema, it does not clarify what 'full details' includes or what the response structure looks like. It also does not differentiate from the career job endpoint, which could matter in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it rephrases the `include` parameter and says 'by ID or alias,' which the schema already documents. No new semantic details are provided.
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 function: 'Get full details of a job by ID or alias.' This is a specific verb+resource action and distinguishes it from sibling tools like hires_list_jobs (which lists jobs) and hires_get_career_job (which targets public career jobs). The mention of loading related data via `include` further clarifies its scope.
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 have a job ID or alias and need full details, but it does not explicitly state when to prefer this over alternatives like hires_list_jobs or hires_get_career_job. There are no stated exclusions or direct comparisons, so guidance is clear but not explicit.
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 must carry the full burden of behavioral disclosure. It states it's a list operation and supports filtering by event type, but doesn't indicate pagination behavior, read-only confirmation, or return format. This is moderate transparency for a simple list 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, front-loaded sentence that immediately states the action and resource, includes relevant examples, and mentions filtering. No unnecessary words 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 no output schema and no annotations, the description explains the core intent and filtering capability. However, it omits pagination details and response structure, which are non-trivial given the page parameter. It's 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?
Schema description coverage is 100%, so all three parameters are already documented. The description only rephrases the event_type filter, which already contains the supported values in the schema, adding no new semantic value. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies 'List timeline activities for a candidate' with concrete examples (comments, stage moves, AI responses). This distinguishes it from other candidate list tools like interviews or messages. It also mentions filtering support, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are provided. The description implies usage for retrieving candidate activity timelines, but doesn't mention exclusions or when not to use. It's implied usage only, not explicit guidance.
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 carry the full disclosure burden. It reveals the aggregation behavior ('across all applications') and hints at use cases, but does not disclose output structure, ordering, pagination defaults, or authentication requirements. This is comparable to sparse descriptions that score 2.
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?
Two sentences, front-loaded with the primary action and followed by use cases. No redundant or filler language.
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 is a simple paginated list with no output schema, but the description does not specify return fields, ordering, or pagination defaults. It provides use cases but lacks behavioral details that would help an agent interpret the response. Adequate for basic selection but not 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?
The input schema covers all three parameters with descriptions (id, page, size), so the baseline is 3. The description adds context that the id refers to a candidate and that interviews span all applications, but it does not elaborate on page/size semantics beyond the 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 uses a specific verb ('List') plus the resource ('interviews for a candidate') and scope ('across all applications'), clearly distinguishing it from sibling tools like hires_list_interviews (global) and hires_get_interview (single).
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?
It explicitly states the tool's use cases ('timeline views and scheduling conflict detection'), and the 'across all applications' scope differentiates it from alternatives. However, it does not explicitly mention when not to use it or compare it to similar list 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 behavioral burden. It only says 'Change job status' without disclosing side effects, required permissions, valid status values, or response behavior. This is a significant gap 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 two sentences, each earning its place: the first states the action, the second gives usage guidance. No wasted words and the core purpose is 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?
With no output schema and no annotations, the description omits return value and error behavior, which are relevant. However, the parameter schema is fully documented, and the use-case guidance helps an agent decide when to invoke it. It is minimally adequate but not rich in 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 coverage is 100%, so the baseline is 3. The description's mention of publish/unpublish/archive transitions hints at acceptable status values but adds no practical detail beyond the schema's existing parameter descriptions.
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 states the specific action ('Change job status') and resource ('job status'), and distinguishes from sibling tools by noting it is a dedicated endpoint for publish/unpublish/archive transitions and automation workflows. This clearly separates it from general update_job or publish_to_job_board tools.
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?
It explicitly recommends use for publish/unpublish/archive transitions and status automation workflows, providing clear context for when to use it. It does not explicitly name alternatives or list exclusions, but the 'dedicated endpoint' phrasing implies it is the preferred tool for status changes.
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 transparently discloses that a new application is created on the target job, which is an important behavioral trait. However, it remains silent on what happens to the original application (e.g., deleted, archived, or left unchanged), and it does not mention permissions, side effects, or other consequences. This is a significant gap for a mutation tool without 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 two concise sentences with no filler. The first states the core action, and the second adds an important behavioral detail and the optional stage context. Every word serves a purpose, and the structure is clear and 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?
With four parameters, no annotations, and no output schema, the description covers the main purpose and the optional stage but omits the fate of the original application and the behavior of the 'include' parameter. It also does not describe the return value. Given the tool's complexity and lack of annotations, this level of completeness is moderate but leaves important gaps for an agent to invoke safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions 'Optionally specify a stage,' but the schema already explains stage_id and its default. The 'include' parameter is not mentioned in the description, though the schema covers it. Thus the description provides minimal added meaning over the structured parameter descriptions.
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 uses a specific verb ('Transfer') and clearly identifies the resource ('an application') and target ('another job'). It also states the key effect ('A new application is created on the target job'), which distinguishes it from sibling tools like hires_move_application that may operate within the same job. This is a clear, non-tautological statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (transferring an application to a different job) and mentions the optional stage, but it provides no explicit guidance on when to use this tool versus alternatives such as hires_move_application or hires_batch_move_applications. There is no when-not-to-use or alternative reference, leaving some ambiguity for an agent choosing among related application-mutation 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 the full burden. It only says 'update' without disclosing critical behaviors: text and type are required by the schema, so a partial update is impossible; it does not mention idempotency, side effects, or error conditions. This gap is significant 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 concise sentence that starts with the verb 'Update' and lists the target fields. Every word earns its place with no 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?
For a simple update tool, the description plus schema covers basic parameter meaning. However, it omits update semantics (full replace vs partial), the fact that text and type are mandatory even when only options change, and there is no output schema to describe return values. Sibling tool hires_update_form_question is not contrasted.
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 descriptions cover 100% of parameters (id, text, type, options), so the baseline is 3. The description merely names the same fields ('text, type, or options') without adding further semantic value like allowed values 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 action (update) and the resource (existing question definition), and specifies the updated fields (text, type, options). This differentiates it from siblings like hires_create_question, hires_get_question, and hires_update_form_question.
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 phrase 'existing question definition' implies this is for modifying already-created questions, providing clear context. However, it does not explicitly mention alternatives or when not to use it, and the sibling hires_update_form_question exists which could cause confusion.
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, the description carries the burden of behavioral disclosure. It only states the action and payload type, omitting side effects, permissions, file size limits, overwrite behavior, or return values. This is insufficient 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 two short sentences, front-loaded with the primary action and followed by use cases. No filler 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?
For a tool with no annotations and no output schema, the description covers the basic purpose and use cases but does not mention response behavior, constraints, or distinctions from similar upload tools. It is adequate but not 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?
The input schema already fully describes both parameters (id and file) with 100% coverage. The description adds only the base64 payload detail and use cases, which slightly reinforces but does not significantly extend schema meaning. Baseline 3 applies.
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 'Upload a file for a candidate using a base64 payload' – a specific verb, resource, and method. It distinguishes from sibling upload tools like hires_upload_application_attachment by specifying candidate files and listing use cases (resume, portfolio, document).
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 usage context ('Used for resume ingestion, portfolio uploads, and document attachment') but does not explicitly contrast with alternative tools like hires_upload_application_attachment or mention when not to use it. This is moderately clear but lacks 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 the full burden. It states the action ('Add') but does not disclose side effects, permissions, idempotency, or behavior if the member already exists. More depth is needed 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?
Two short sentences, no filler, and the key information is front-loaded. Every word contributes to understanding the tool's purpose and usage.
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 two-parameter add operation with full schema coverage, the description is largely complete. It could mention expected response or error cases, but the absence is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains both parameters clearly (id as job ID, user_id as user to add). The description adds no extra parameter detail, which is acceptable given high schema coverage, but it also does not reinforce the relationship between the parameters and the purpose.
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 uses a specific verb ('Add') and identifies the resource ('company member to the job's hiring team'), clearly distinguishing it from sibling tools like hires_list_hiring_team. It also includes a usage context ('workflow setup and ownership automation') that reinforces purpose.
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 an explicit use context: 'Use in workflow setup and ownership automation.' It does not state exclusions or alternatives, but the context is clear enough to guide when to invoke 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?
No annotations are provided, so the description carries the full burden. It only states 'Create a company-scoped webhook subscription' without disclosing side effects, permissions, idempotency, or what the response will contain. For a mutation tool, 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 consists of two short, front-loaded sentences with zero filler. Every word contributes to the tool's purpose and usage context, making it highly concise.
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 (two well-documented parameters) and clear company-scoped purpose, the description covers the essential context. Some return-value information would improve completeness, but the lack is not critical for such a straightforward create operation.
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 describes both parameters (id as Company ID and url as Webhook destination URL with HTTPS requirement), giving 100% coverage. The description adds no additional parameter meaning beyond what already exists in the schema, so the baseline of 3 applies.
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 'Create a company-scoped webhook subscription', specifying a concrete verb (Create) and resource (webhook subscription). The 'company-scoped' qualifier distinguishes it from the sibling tool hires_create_job_webhook, so 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use for outbound company-level event integrations' provides clear context on when to use the tool. It does not explicitly mention alternatives or exclusions, but the company-scoping in the description contrasts with job-scoped webhook siblings, offering implicit guidance.
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, the description carries the burden of behavioral disclosure. It states 'permanently delete,' which signals irreversibility. However, it does not disclose other potential behaviors such as cascading deletions, permission requirements, or response semantics, leaving a partial picture.
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, front-loaded sentence that directly states the tool's purpose and method. Every word earns its place, with no unnecessary repetition or filler.
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 delete tool with one parameter and no output schema, the description provides the essential information: what action, on what resource, and how to identify it. It could mention return behavior or side effects, but given the simplicity, it is reasonably 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?
The input schema already documents the sole parameter fully (Candidate ID (integer) or alias (string)), and the description's mention of 'by ID or alias' only restates this. Schema description coverage is 100%, so the description adds no additional parameter meaning beyond the baseline.
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 action ('Permanently delete') and the resource ('a candidate'), along with the identification method ('by ID or alias'). This is specific and distinguishes it from sibling tools like get, update, or disqualify.
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 gives clear context that deletion is permanent, which implies a destructive operation. However, it does not explicitly mention when to use this tool versus alternatives like disqualify_candidate or reject_application, nor does it provide exclusions or when-not-to-use guidance.
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 should disclose behavioral traits such as irreversibility, required permissions, or error behavior. The description only states 'Delete' without mentioning any side effects or risks, leaving the agent without guidance on permanent mutation.
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?
Two short sentences, front-loaded with the action, and each phrase earns its place. No filler or 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?
The tool is a deletion operation with no output schema, and the schema covers both required parameters. The description provides purpose and common use cases, but it lacks explicit warnings about permanence or clarification of the relationship between job ID and webhook ID, which could be ambiguous given the sibling tool name.
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 says 'by ID' but does not clarify which of the two required parameters (id and webhook_id) identifies the webhook. However, the input schema provides descriptions for both parameters with 100% coverage, so the schema already handles parameter semantics; the description adds no additional meaning.
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 uses a specific verb ('Delete') with a clear resource ('job webhook subscription') and indicates the identifier method ('by ID'), distinguishing it from generic webhook deletion tools like hires_delete_webhook.
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 phrase 'Use for cleanup, rotation, and endpoint migration' provides explicit usage context for when this tool should be invoked. However, it does not explicitly distinguish from the sibling hires_delete_webhook or state when not to use it, though the 'job' qualifier implies a narrower scope.
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 that the operation deletes the webhook but does not mention permanence, error handling, permission requirements, or idempotency. For a destructive operation, this is minimal 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 exactly two sentences, front-loaded with the core action and resource, and includes practical use cases without unnecessary fluff. Every word earns its place.
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 two-parameter delete tool with no output schema, this description is nearly complete. It identifies the resource, the required identifier, and when to use it. It could mention irreversible consequences or error behavior, but the given context is sufficient for typical agent 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 coverage is 100% with both parameters described ('Company ID', 'Webhook ID'). The description adds little beyond the schema—'by ID' restates what the schema already implies. Baseline 3 is appropriate.
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 action ('Delete'), the target resource ('webhook subscription'), and its scope ('company-scoped'), and specifies the identifier ('by ID'). This distinctively differentiates it from sibling tools like 'hires_delete_job_webhook' or 'hires_delete_candidate'.
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 first sentence defines the function, and the second provides concrete use cases ('endpoint retirement and security rotation'). While it doesn't explicitly name alternative tools or exclusions, the context is clear enough for selecting this tool over similar delete 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 must carry the behavioral burden. It states the return content (full details, subject, body) and the 'Get' verb implies a read-only operation, but it does not mention error cases, permissions, or whether it has side effects. Provides some context but not comprehensive.
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?
One sentence, 16 words, front-loaded with the action and resource, no 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?
For a simple single-parameter read tool, the description sufficiently covers the purpose and expected output (subject and body content). However, it omits any details about error handling or response format, but given no output schema, it minimally covers the essentials. Slight room for improvement.
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 coverage is 100% for the single 'id' parameter, which is already described as 'Email template ID'. The description's 'by ID' adds no new semantic meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' + resource 'email template' + identifier 'by ID' and specifies the returned content (subject, body), clearly distinguishing this from siblings like list/create/update/delete.
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?
Description implies use when you have a specific template ID and need its full details, but does not explicitly state when to use this versus list_email_templates or mention exclusions/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 responsibility for behavioral disclosure. It only states what the tool does ('Get full details') without mentioning response format, authorization needs, error behavior, or any other operational traits. This is a significant gap 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 two sentences, front-loaded with the core purpose, and has no redundant or filler content. It is efficient and to the point.
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 get-by-ID tool with two parameters and no output schema, the description is reasonably complete. It states that the response contains 'full details' and explains the include option. It could be enhanced with an example response or return format, but it is not critically incomplete.
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 already provides complete descriptions for both parameters (id and include). The description's mention of 'include to embed related candidate, application, or job data' adds no new semantic information beyond the schema. Baseline 3 applies due to high 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 'Get full details of a specific interview by ID' with a specific verb and resource. It distinguishes from sibling tools like hires_list_interviews by focusing on a single item retrieval.
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 implies usage for retrieving a specific interview by ID and hints at optional embedding with 'include'. It provides clear context but does not explicitly mention alternatives such as list_interviews for fetching multiple interviews.
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, the description carries the burden of behavioral disclosure. It communicates that this is a read operation and describes return content ('sender account, schedule timestamps, cancelability'), but it omits details on error cases, authorization requirements, or any side-effect-free guarantee beyond the 'Get' verb.
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 two sentences, front-loaded with the core action, and every word adds value. It avoids repetition and fluff.
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 one-parameter GET tool with no output schema, the description sufficiently explains the purpose and key returned fields. It could be more complete by mentioning alternative tools or potential error behavior, but overall it is adequate for the low complexity.
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 coverage is 100% with the parameter 'id' described as 'Message ID.' The description adds no additional meaning beyond re-stating 'by ID', so it does not elevate above the schema baseline.
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 a specific verb ('Get') and resource ('scheduled message by ID'), and it distinguishes from sibling tools like hires_list_messages and hires_get_notification_message by emphasizing 'scheduled' and 'scheduler-backed'.
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 its use through 'by ID' and 'scheduled message', but it does not explicitly state when to choose this over alternatives or mention any exclusions. No comparison to list/update/delete tools is provided.
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 states this is a read operation ('Get') and includes content ('type and options'), but does not disclose error behavior, authorization requirements, or whether all fields are returned. Minimal but acceptable for a straightforward get-by-ID 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?
A single, concise sentence that conveys the action, resource, and key content. No wasted words or redundant details.
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 low-complexity get-by-ID tool, the description is mostly complete. It mentions the return includes type and options, which is useful in the absence of an output schema. It could be more explicit about other possible fields, but given the simplicity, it's 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 schema fully documents the single 'id' parameter ('Question ID'), so the description adds no additional meaning. Schema coverage is 100%, meeting the baseline of 3.
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 action ('Get') and resource ('question definition including type and options') with a specific identifier ('by ID'). This distinguishes it from sibling tools like hires_list_questions and hires_create_question.
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 have a specific question ID and need its full definition. It does not explicitly mention alternatives or when not to use it, but the 'by ID' qualifier offers implicit guidance. Absence of explicit comparison to list/create tools makes this an implied 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 the full burden of behavioral disclosure. It states the operation is a getter but does not disclose return type, pagination, ordering, error conditions, or authentication requirements. It only adds the equivalence note, which is more about purpose than behavior. This is a significant gap for a tool with no 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?
Two sentences, front-loaded with the primary action, and no wasted words. The equivalence note is tightly integrated into the second sentence, making the description efficient and easy to scan.
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 getter with fully documented parameters and no output schema, the description conveys the essential context. It explains the relationship to the sibling list tool, which helps the agent choose appropriately. However, it omits details about the response shape or potential pitfalls, leaving slight room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (id and company_id) thoroughly. The description adds no additional parameter meaning beyond the schema, meeting the baseline but not exceeding it.
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 gets stages for a specific workflow by ID. It further distinguishes itself from the sibling tool hires_list_workflow_stages by explicitly noting equivalence with a workflow_id filter, making its scope 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 usage context by naming the equivalent alternative (hires_list_workflow_stages with workflow_id filter). While it does not explicitly state 'use this when you have a workflow ID', the equivalence implies the appropriate use case, offering reasonable guidance without specifying exclusions.
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 what each evaluation includes (evaluator, summary score, summary text) and uses the verb 'List' to imply a read operation. However, it does not mention return format, pagination, error behavior, or permission requirements, which would enhance transparency for a list endpoint.
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 two sentences, front-loads the primary purpose, and then adds concise details about the evaluation content. Every word adds value with no redundancy or fluff, making it highly efficient.
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 one-parameter list tool, the description provides the core functionality and output field details. While it lacks explicit pagination or error handling notes, the simplicity of the tool and the input schema make the description sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'id' is already described as 'Application ID.' The description merely reinforces this by saying 'for an application' without adding new semantic details like value ranges or requirements. The schema carries the descriptive burden, so the baseline score of 3 applies.
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 'List all filled evaluation forms for an application,' providing a specific verb, resource, and scope. It distinguishes itself from sibling tools like 'hires_get_evaluation' (single evaluation) and 'hires_list_forms' (all forms) by focusing on application-specific evaluations.
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 usage context is implied: use this when you need evaluations for a given application ID. However, it does not explicitly state when not to use it or mention alternatives, such as 'hires_get_evaluation' for a single evaluation. No clear exclusions or alternative guidance is provided.
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 lists (read operation), supports pagination, and returns name, subject, and body. However, it does not mention permission requirements, behavior when company_id is omitted (since all params are optional), or error cases.
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 two sentences, front-loaded with the primary purpose, and concise. Every word adds value, with no redundancy or fluff.
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 list tool with no output schema, the description covers purpose, pagination, and return fields. It does not clarify behavior when company_id is not provided (since no params are required), which is a minor gap. Otherwise, it is reasonably 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 100%, so each parameter already has a description. The tool description adds minimal value: it reinforces 'target company' for company_id and mentions pagination, but does not provide new semantic meaning beyond the 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 states 'List email templates for the target company,' which is a specific verb+resource with clear scope. It also mentions paginated results and returned fields (name, subject, body), distinguishing it from sibling tools like get_email_template, create_email_template, etc.
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 this tool is for listing templates scoped to a company, but it does not explicitly state when to use it versus alternatives like get_email_template or other list tools. No exclusions or context for 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses pagination behavior ('Returns paginated results'), which is helpful. However, it doesn't mention ordering, default page size, or authentication requirements, and it doesn't add richer behavioral context beyond what the name implies.
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?
Two concise sentences that front-load the action and filter options, ending with pagination. Every word serves a purpose; no filler.
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 list endpoint with no output schema, the description covers the core functionality: what it lists, filter options, and pagination. It doesn't describe response fields or error handling, but given schema coverage, it is 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?
All 10 parameters are described in the schema (100% coverage), so the description only summarizes them via filter categories. It adds minimal value by grouping filters into 'job, application, candidate, interviewer, date, or timestamps', which aligns with the 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?
Clearly identifies the tool as listing interviews, with a specific verb and resource. Names the filter dimensions, which distinguishes it from generic listing tools, though it doesn't explicitly contrast with sibling tools like hires_list_candidate_interviews.
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?
States optional filters and the incremental sync use case, giving clear context for when to use. Does not explicitly mention alternatives or exclusions, but the conditions are well understood from the purpose.
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?
The description discloses that results are paginated, which is a key behavioral trait not evident from the name. There are no annotations, so the description carries the burden, but it does not explicitly state read-only nature, error conditions, or rate limits. For a simple list operation, it provides moderate 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 three concise sentences, front-loaded with the action and followed by behavioral and use-case details. No filler words; every sentence adds value. This is exemplary conciseness.
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 absence of an output schema and annotations, the description covers the core functionality and pagination behavior. It omits detailed response structure, but for a filtered list with a rich schema, the description is sufficiently complete for an agent to invoke it appropriately. The use cases add 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 already covers all 10 parameters with descriptions, so the baseline is 3. The description's mention of filters by status, date range, department, or search query maps to the schema but doesn't add deeper semantics. It does not clarify any ambiguity in parameter interactions, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'List jobs with optional filters', using a specific verb and resource. It does not explicitly distinguish from the sibling tool hires_list_career_jobs, though the mention of 'career-site sync' hints at context. Overall, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases ('career-site sync, reporting, and external system indexing') which indicate when to use this tool. It does not offer exclusions or alternatives, so it slightly under-serves the 'when not to use' aspect. This is clear context, though not fully differentiating.
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 burden. It discloses that results are summaries including steps, which is useful. However, it does not mention pagination limits, default sorting, or confirm read-only behavior. 'List' implies non-destructive but this is not explicit.
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 two short sentences, immediately states the action, and avoids unnecessary detail. Every word contributes value.
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 list tool with no output schema and no annotations, the description provides the core function and return content. It could mention the scope (e.g., all nurture campaigns for the company) but the schema covers company_id optionality. Overall it is sufficiently complete for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already explained. The description adds 'pagination' context and mentions summaries, but this is largely redundant with the schema. It does not significantly deepen understanding of page/size/company_id beyond their existing descriptions.
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 'List nurture campaigns with pagination', using a specific verb and resource. It also notes that it returns summaries including steps, which distinguishes it from a 'get' operation and from other list 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 this tool is for listing nurture campaigns, but does not explicitly state when to use it instead of alternatives like get_nurture_campaign or other list tools. No exclusions or alternative guidance is 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?
There are no annotations, so the description carries the full burden. It only states that it lists mail accounts and mentions `from_account_id`, but it does not disclose pagination behavior, required permissions, or any potential side effects. The behavioral context is minimal.
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 two concise sentences, front-loaded with the primary purpose, and includes a practical use case without any superfluous text.
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?
No output schema exists and the tool is simple. The description explains the main purpose and a specific use case, which is sufficient for basic invocation. It could mention the return format, but overall it is adequately 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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add extra meaning beyond the schema; it only references `from_account_id` without detailing how parameters map to the output.
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 identifies the tool as listing mail accounts connected to a user, using a specific verb and resource. It also distinguishes itself from sibling list tools by emphasizing user-specific accounts rather than company accounts.
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 explicitly states when to use the tool: to resolve `from_account_id` before creating scheduled emails. It provides clear context but does not mention when not to use it or name alternative tools.
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 burden of behavioral disclosure. It does state the primary create action and optional steps (link to job/stage, attach CV), but doesn't mention potential side effects like creating an application or how deduplication works, which are important for a create 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?
Two sentences, front-loaded with the purpose, then optional features, then use cases. Every word earns its place; no unnecessary detail or repetition.
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 is adequate for a 9-parameter tool with nested objects, but it doesn't explain key nuances like whether linking to a job/stage creates an application, the deduplication behavior, or how it differs from hires_create_application. More detail would make it 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 100%, so the parameters are well-documented. The description adds context by mentioning 'link to a job/stage' and 'attach a CV', but doesn't provide semantic details beyond what the schema already offers. Baseline 3 is appropriate.
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 action ('Create a new candidate profile') and identifies the resource, which distinguishes it from sibling tools like update_candidate or delete_candidate. It also mentions optional linking to a job/stage and CV attachment, further clarifying scope.
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 explicitly states when to use this tool: 'Used for imports, inbound forms, and enrichment workflows.' This provides clear context, though it doesn't explicitly exclude alternatives or mention 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 full disclosure burden. It only states the action and resource without mentioning read-only behavior, return format, pagination, or permissions. The verb 'list' implies a read operation, but the description does not explicitly disclose any 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, 9-word sentence that front-loads the action and resource. It contains no filler words and earns its place by also adding the use-case context.
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 (no parameters) and no output schema, the description explains the tool's purpose but does not describe the shape of the return value (e.g., whether it returns IDs, labels, objects). This is a gap for full completeness, though invocation is straightforward.
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 zero parameters, so the input schema is trivially fully covered. The rule states that with 0 params, the baseline is 4; the description does not need to add parameter details and does not detract from the 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 uses the specific verb 'List' and identifies the resource as 'experience level taxonomy values', which clearly differentiates it from sibling tools like list_education_levels or list_employment_types. The added phrase 'role seniority modeling' provides further contextual purpose.
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 phrase 'for role seniority modeling' gives clear application context, implying when this taxonomy list would be needed. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusions but still offers clear context.
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, the description carries the burden of behavioral disclosure. It clearly implies a mutation ('Move an application') and explains the need for a target stage. However, it omits potential side effects, authorization requirements, or failure behavior, leaving some uncertainty about the operation's full impact.
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 two sentences long, front-loads the core action, and includes only essential context. Every sentence earns its place with no redundancy or filler.
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 relatively simple mutation tool with full schema coverage, the description provides enough context for correct selection and invocation. It explains the purpose, the key parameter source, and the use case. It does not describe return values, but there is no output schema and the action is straightforward.
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 schema already documents all three parameters with 100% coverage. The description adds meaningful semantic value by explaining that stage_id is the target stage and where to get it ('get it from the job's pipeline_stages'). This elevates it above the baseline 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 function: 'Move an application to a specific pipeline stage.' It also adds context about explicit stage transitions. However, it does not explicitly distinguish itself from closely related siblings like hires_advance_application or hires_transfer_application, so it stops short of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context ('Use this for explicit stage transitions in workflow orchestration') and practical guidance for obtaining the required stage_id from the job's pipeline_stages. It does not mention when not to use it or name alternatives, which is the only gap.
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 burden of disclosing behavior. It usefully states that only provided fields are changed and that the update must occur before send time, which is meaningful. However, it does not disclose permissions, error behavior, or whether updates are reversible, so it is only moderately transparent.
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 front-loads the verb and resource, then adds the key constraint. There is no redundancy or filler.
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 core purpose and the main timing constraint, and the schema richly documents all parameters. However, with no annotations and no output schema, it could include more context about return values, failure cases, or how this differs from the full update tool. It is 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?
Schema coverage is 100% and each parameter already has a meaningful description. The description adds a global semantic ('Only provided fields are changed') but does not elaborate on any specific parameter beyond what the schema already provides, matching the baseline for high 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 begins with a specific action ('Partially update') and names the resource ('a scheduled message'), and adds the important constraint 'before send time.' The phrase 'Only provided fields are changed' clarifies partial semantics, distinguishing it from the full-update sibling tool hires_update_message.
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?
It gives clear context for when to use the tool: for partial updates to scheduled messages before they are sent. It does not explicitly mention when not to use it or name an alternative tool, so it falls just short of a 5.
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 default scheduling behavior, which is valuable, but does not mention side effects (e.g., actual email send), permissions, or error handling. The scheduling nuance is disclosed, so it meets a minimum bar but lacks richer 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?
Two sentences, front-loaded with the primary action, and zero wasted words. It states the essential purpose and the key default behavior 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?
The description covers the core function and a critical default, but given 11 parameters and no annotations or output schema, it leaves some context implicit, such as the return value, prerequisites (e.g., valid candidate ID), and behavior on failure. However, the schema covers parameter details well, so the description is adequate but not 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 input schema has 100% coverage of all 11 parameters with descriptive text. The description adds the default timing for scheduled_at, but the schema already specifies this same detail. Therefore, the description does not provide significant added meaning beyond the 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 uses a clear verb ('Schedule') and resource ('email message to a candidate'), which precisely states the tool's function. It distinguishes itself from sibling tools by focusing on sending/scheduling messages to candidates, not other entities or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates the scheduling context and the key default behavior (scheduled 15 minutes after creation if omitted). It does not explicitly state when to avoid this tool or mention alternatives, but the context is sufficiently clear for selecting it over generic message 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, the description carries the full burden of behavioral disclosure. It mentions updating stage, disqualification, and CV, but does not disclose side effects such as whether disqualification triggers notifications, whether CV replacement is irreversible, or any authorization requirements. The description adds little beyond what the schema already states, leaving significant behavioral ambiguity.
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 compact and well-structured: the first sentence states the core functionality with examples, and the second sentence gives a clear pointer to alternatives. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (5 params, 1 nested object), the description is functional but minimal. It effectively differentiates from siblings but does not cover the full update surface (e.g., include parameter is not mentioned) or explain return values. The schema fills some gaps, but for a mutation tool without annotations, the description is not fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description names a few parameters (stage, disqualification flag, CV) but does not add detail beyond the schema's own descriptions. It provides a helpful high-level mapping but no extra semantic depth, so it neither improves nor detracts from the schema's clarity.
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 function: updating application fields like stage, disqualification flag, and CV. It distinguishes itself from sibling tools by explicitly pointing to hires_move_application and hires_advance_application for explicit stage transitions, making its purpose and scope 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 usage guidance: use this for general updates, but prefer specialized siblings for stage transitions. This directly addresses when to use this tool vs alternatives, which is exactly what this dimension requires.
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 burden of behavioral disclosure. It conveys full-replace behavior and the 'before send time' constraint, which is valuable. However, it does not disclose what happens to omitted optional fields (whether they are reset or preserved), the response format, or any permission requirements. This leaves meaningful 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 concise and front-loaded, using two short sentences to convey the core action and a key constraint. There is no redundancy or filler.
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 10-parameter mutation without an output schema or annotations, the description provides the essential 'full replace' behavior and timing constraint but omits other important context such as the fate of unspecified optional fields, return values, and error conditions. The high schema coverage compensates for parameter explanation, but behavioral completeness is only partially addressed.
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 100% coverage for all 10 parameters, so the description need not repeat parameter meanings. The only added semantic is the requirement that all required fields must be provided, which is already indicated by the schema's 'required' array. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a full update/replacement of a scheduled message before send time. The verb 'update' with 'replace' and the specific resource 'scheduled message' precisely define the action, and the phrase 'All required fields must be provided' distinguishes it from partial-update siblings like hires_patch_message.
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 gives important usage context: this is for scheduled messages before send time, and all required fields must be provided. It implies a contrast with partial updates (likely hires_patch_message), though it does not explicitly name alternatives. This is clear but not fully explicit about when-not-to-use.
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, the description carries the full burden of behavior disclosure. It explicitly mentions 'Returns per-item results with partial success support', which is a valuable behavioral trait beyond the schema. The max-100 limit is also disclosed, but additional side effects (e.g., duplicate handling) are not addressed.
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 one sentence, front-loaded with the core purpose, and includes key details (max 100, per-item results, partial success) without any fluff or redundancy. Every word earns its place.
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 two-parameter operation with no output schema, the description provides the essential information: action, batch limit, and return behavior. It is complete enough for an agent to invoke correctly, though it might benefit from a brief note on how partial success is indicated in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'ids' and 'tags' already described in the input schema. The tool description adds no further parameter-specific meaning beyond confirming the batch context, so the baseline of 3 is appropriate.
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 'Add tags to multiple candidates in one request', specifying the action (add tags), resource (candidates), and batch scope. This differentiates it from single-candidate tag operations like 'hires_add_candidate_tags' and the opposite 'hires_batch_remove_tags'.
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 phrase 'in one request' and 'max 100' imply a batch use case, but the description does not explicitly provide when-not-to-use guidance or name alternatives like single-tag tools. Usage is implied rather than explicitly contrasted with siblings.
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 for behavioral transparency. 'Get' implies a read-only operation, and 'in one request' hints at batch efficiency, but it doesn't explicitly confirm that no data is modified, nor does it describe edge cases like invalid job IDs or partial failures. Lacks depth but is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the core action and then provide the intended use case. Every word earns its place, with no filler or 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?
For a simple one-parameter read operation, the description gives sufficient context for an agent to select and invoke it. It clearly states what the tool does and when it's useful, though the lack of an output schema means the return format is not explained. This is a minor gap for such a focused batch getter.
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 already provides 100% coverage with a clear description of the 'jobs' parameter as an array of job IDs. The description adds the phrase 'multiple jobs in one request,' which reinforces the batch nature but doesn't offer additional syntax, limits, or behavioral details beyond the 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 verb ('Get') and resource ('board publication states') with a specific scope ('for multiple jobs in one request'). This distinguishes it from sibling tools that publish/remove jobs from boards, 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 usage context: it is 'Optimized for batch monitoring and management UIs,' implying the tool is intended for retrieving states for multiple jobs at once. It doesn't explicitly mention alternatives or exclusions, but the batch focus is evident.
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 does disclose key behaviors: 'Returns per-item results with partial success support' and the max request size. However, it does not mention potential side effects, reversibility, authentication requirements, or what happens on validation failures, leaving some uncertainty 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 three concise sentences that front-load the core purpose, then immediately convey the critical return behavior and limit. Every sentence adds value with no fluff or repetition.
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 batch operation with no output schema and no annotations, the description covers the essential context: batch capabilities, partial success support, and request limits. It does not specify the exact structure of per-item results or error handling, but the provided details give an agent enough to anticipate behavior. This is more than minimally viable but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'ids' and 'stage_id' have clear descriptions. The tool description adds minimal parameter-level detail beyond stating the 100-ID limit, which is already in the schema. Since the schema handles parameter meaning, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Move' and the resource 'applications', specifying the batch nature ('multiple applications') and destination ('to a pipeline stage'). It clearly distinguishes from the sibling tool hires_move_application by emphasizing 'multiple' and 'in one request', making the batch intent 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 indicates when to use this tool: when moving multiple applications in a single request, with a stated limit of 100 IDs. While it doesn't explicitly mention alternatives, the clear batch focus and the count limit imply it should be used over the single-application move tool for bulk operations. It lacks explicit 'when-not-to-use' guidance but provides enough context.
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 of behavioral disclosure. It mentions the candidate must already exist, but does not disclose potential side effects, duplicate handling, or permission requirements. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and usage context. Every word earns its place, with no 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?
For a create tool with 5 parameters and one nested object, the description covers the primary purpose and key prerequisite. It omits details about optional fields (cv, stage, include) and the expected response, but the schema fully documents parameters, making the description adequate for correct 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 coverage is 100%, so the baseline is 3. The description adds little beyond the schema, though the phrase 'linking an existing candidate to a job' reinforces the roles of candidate_id and job_id. No extra parameter details are provided.
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 action ('Create an application') and the method ('by linking an existing candidate to a job'), distinguishing it from sibling tools that update, get, list, or delete applications. It also mentions sourcing workflows, adding clarity on its role.
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 explicitly says 'Use for sourcing workflows and manual application ingestion' and provides a clear prerequisite ('The candidate must already exist'). It does not name alternative tools like create_candidate, but the context is sufficient to guide the agent toward the correct use case.
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 burden and discloses key behavior: the deletion is permanent and removes the application from all queries. However, it does not mention potential side effects on associated data (e.g., interviews, notes, attachments).
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 two concise sentences, front-loaded with the core action and followed by the consequence. No extraneous information is present.
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 one-parameter delete tool with no output schema, the description adequately covers the action, permanence, and visibility effect. It could be enhanced by noting cascading deletions or error behavior, but the current description is sufficiently complete for 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 coverage is 100% with a clear property description ('Application ID.'), so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides.
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 a specific action ('Permanently delete') and resource ('an application'), and it differentiates from sibling tools like reject or archive by emphasizing permanent removal from all list and view queries.
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 when to use the tool (for permanent deletion) but does not explicitly discuss alternatives such as rejecting or transferring an application, nor does it provide exclusions or prerequisite conditions.
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 transparency burden. It discloses that the operation is a soft-delete and explains the side effect on templates used in automations, which is valuable behavioral context. It does not mention reversibility or permissions, but the core side effect is addressed.
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 two sentences, front-loaded with the action, and contains no redundant words. Every sentence earns its place, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description provides sufficient context: the action, the soft-delete nature, and the automation consequence. It lacks explicit reversibility details, but given the low complexity and complete schema coverage, the description is largely 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?
The input schema fully documents the single `id` parameter with a clear description ('Email template ID'), giving 100% schema coverage. The description does not add any additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Soft-delete an email template' – a specific verb and resource. The second sentence adds context about the impact on automations, which distinguishes this from a simple hard delete and clarifies the tool's scope.
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 deleting email templates but does not explicitly state when to use it versus alternatives like updating the template. The automation impact is a consequence rather than a direct usage guideline, so guidance is inferred rather than clearly provided.
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 behavioral disclosure burden. It states the action (cancel) and the condition (before processing), but does not explain side effects, reversibility, or permission requirements. The description is non-contradictory but limited in depth.
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 entire description is a single front-loaded sentence with no redundant words. Every word adds meaning, making it highly efficient.
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 one-parameter cancel operation, the description adequately conveys the purpose and timing. It could mention the return value or behavior when the message has already been processed, but these are not critical for understanding the tool's function.
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 provides a 'Message ID.' description for the 'id' parameter, and the description does not add further semantic detail about the parameter. Since schema coverage is 100%, a baseline score of 3 is appropriate.
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 uses the specific verb 'Cancel' and identifies the resource as 'a scheduled message', clearly distinguishing this from other message-related tools like delete_message or update_message. It also adds the timing constraint 'before it is processed by the mailbox scheduler', which defines the exact scope.
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 implies the tool should be used when a scheduled message needs to be canceled prior to processing by the mailbox scheduler. It does not explicitly name alternatives or exclusions, but the context is clear that this is for scheduled messages, not sent or draft messages.
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, the description carries the burden of disclosing behavior. It mentions the mutation ('Disqualify'), the scope ('all active applications'), and the output ('Returns affected application IDs'). However, it does not disclose whether the action is reversible, what permissions are needed, or any side effects (e.g., notifications). This is a notable gap 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 two concise sentences, front-loaded with the main action and scope. Every sentence provides value: the first defines the action, the second covers optional input and return value. No wasted words.
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 tool with two well-documented parameters and no output schema, this description covers the essential context: the scope of affected applications, optional inputs, and return value. It does not mention reversibility or related tools, but the core usage context is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are already clearly described in the schema. The description only repeats that reasons are optional, which is already evident from the schema's required array. It adds no new meaning beyond what the schema provides.
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 a specific action: 'Disqualify a candidate from all active applications.' It specifies the resource (candidate), the scope (all active applications), and the optional parameter (rejection reason IDs). This distinguishes it from sibling tools like hires_reject_application, which operate on single applications.
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 phrase 'all active applications' clearly implies when to use this tool – when you need to disqualify a candidate across every active application rather than one application at a time. However, it does not explicitly name alternatives or state when not to use it, so it misses the top tier.
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. The verb 'Get' and the recommendation to use it before mutations imply it is read-only, but the description does not explicitly state that no changes are made. It does add useful context about the return content (stage, status, rejection context), which goes beyond the tool name, but lacks details on response format, potential errors, or authorization requirements.
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 only two sentences, front-loaded with the primary action and key details. Every word adds value, and there is no redundancy or fluff. It sets a clear expectation and even includes a usage recommendation without becoming verbose.
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 get tool with two clearly documented parameters and no output schema, the description is adequate. It tells the agent what data is returned (stage, status, rejection context) and when to use it. It does not mention response structure, but the lack of an output schema lowers the burden. A slightly more detailed description of the include parameter or return object would push it to 5.
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 full coverage (100%) for both parameters, with descriptions for 'id' and 'include'. The tool description does not introduce any new parameter semantics; it focuses on output details rather than parameter behavior. Per the rubric, with high schema coverage the baseline is 3, and the description does not need to compensate.
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 retrieves full application details, specifically mentioning stage, status, and rejection context. This distinguishes it from sibling tools like hires_list_applications (list vs. single) and mutation tools like hires_advance_application. The verb 'Get' plus resource 'application' makes the function 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 explicit usage context: 'Recommended before mutating stage transitions.' This tells the agent when to call this tool before performing actions like advancing or rejecting an application. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a full when/when-not comparison.
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 does disclose that the tool returns a note with author and visibility metadata, and explains the effect of the include parameter. However, it does not mention error conditions, permissions, or the exact response structure, which are relevant for a read 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 two concise sentences with the core purpose front-loaded. Every word adds value: the first sentence states what the tool does, and the second provides a key usage tip. There is no redundancy or filler.
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 two-parameter tool with no output schema, this description is sufficiently complete. It informs the agent of the resource, the additional data available, and how to request it. It lacks only a brief note on error handling or return format, but given the simplicity, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'include=user' adds no new semantics beyond the schema's own description of the include parameter ('Include related resources, e.g. 'user' for author details'). The description does not elaborate on the 'id' parameter beyond what the schema provides.
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 function with a specific verb ('Get') and resource ('a single note'), and further specifies what it returns ('author and visibility metadata'). It distinguishes itself from sibling tools like hires_list_notes, which retrieves multiple notes, and from mutation tools like create/update/delete.
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 implies when to use the tool ('Get a single note') and provides concrete usage guidance for the optional 'include' parameter ('Use include=user to load author details'). However, it does not explicitly mention alternatives or offer exclusions, such as 'use hires_list_notes for multiple notes,' which would have strengthened the guidance.
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. It discloses that the operation retrieves a single campaign and includes all steps and configuration details, implying a read-only behavior. However, it does not explicitly state that it is read-only or mention any potential errors or permission requirements, which is a minor 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 one sentence (13 words) and directly states the operation, target resource, and return contents with no fluff or 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?
For a simple single-get tool with one parameter and no output schema, the description covers the core behavior and what the response includes (steps and configuration details). It lacks explicit mention of error handling or authorization, but given the simplicity, the description is sufficiently 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?
The input schema already describes the single 'id' parameter with 100% coverage. The description reinforces that the campaign is fetched by ID but does not add any additional meaning such as format constraints or relationship to list tools. Schema coverage is high, so baseline 3 is appropriate.
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 uses a specific verb 'Get' with the specific resource 'nurture campaign' and adds the detail that it returns 'all steps and configuration details,' distinguishing it from list_nurture_campaigns and other mutation 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 fetching a single campaign by ID, but does not explicitly reference the list_nurture_campaigns tool as an alternative for finding IDs or contrast with create/update/delete. Usage context is clear but no exclusions or alternatives are provided.
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 does disclose the key mutation: the application status changes to 'hired' and hired_at is set. However, it does not mention potential side effects, permissions required, reversibility, or consequences beyond these two fields. The word 'finalization' hints at irreversibility but is not explicit, so the transparency is adequate but not thorough.
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 two sentences with no unnecessary words. The first sentence states the core action, and the second provides the specific effects. It is front-loaded with the verb+resource and remains highly concise, making it easy for an agent to quickly parse the purpose.
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 (2 params, no output schema), the description explains the core behavior and its effects on the application. It lacks information about prerequisites (e.g., current status) or side effects beyond the two stated fields, but it is sufficient for an agent to understand what the tool does. It is nearly complete for a tool of this complexity.
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 already provides descriptions for both parameters, achieving 100% schema description coverage. The tool description itself does not add any additional meaning to the parameters (id and include). Therefore, the description adds no extra value over the schema, and the baseline of 3 is appropriate.
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 ('Mark an application as hired') and the resource ('application'). It further distinguishes itself from sibling tools by labeling this as 'the finalization step in a hiring workflow' and specifying the effects (status changes to 'hired' and hired_at is set). This differentiates it from other application-status tools like reject, advance, or move.
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 phrase 'finalization step in a hiring workflow' provides clear context about when to use this tool—namely, when an application has reached the point of being officially hired. It does not explicitly mention alternatives or exclusions, but the context strongly implies this is for the final hiring decision, distinguishing it from rejection or intermediate moves.
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?
There are no annotations, so the description bears the burden of disclosing behavioral traits. It explicitly mentions that results are paginated and that filters are optional, which conveys read-only, non-committal behavior. However, it does not mention access-control implications, default pagination sizes, ordering, or whether deleted candidates are excluded. The description is adequate but not rich.
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 two sentences long, front-loaded with the primary action, and uses compact language. Every sentence adds information: the first states the resource and optional filtering, the second summarizes filter types and pagination. No filler or redundancy exists.
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 (12 optional parameters, no output schema), the description gives a solid high-level overview of available filters and pagination. It omits some parameter categories (e.g., q, include, company_id) and does not detail the response envelope, but the schema covers these gaps. The description is sufficient for an agent to initiate a candidate list query correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the 12 parameters with descriptions, so the baseline is 3. The description adds only high-level category grouping (job, stage, email, name, LinkedIn, date ranges) without exposing new semantics beyond the schema. It does not clarify relationships like stage_id with job_id or company_id requirements, which are already documented in the 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 a specific action ('List candidates') with a specific resource (candidates) and elaborates on supported filtering capabilities (by job, stage, email, name, LinkedIn, dates). It distinguishes itself from sibling tools that list other entities (e.g., hires_list_jobs, hires_list_applications) by naming the candidate resource and filter variations.
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 conveys when to use the tool: whenever a list of candidates with optional filters is needed. It enumerates the filter dimensions, giving the agent a clear sense of supported use cases. However, it does not explicitly state when not to use it or point to alternatives, such as hiring-specific list operations, so it stops short of a perfect 5.
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 present, so the description carries the full burden for behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not elaborate on authentication, pagination, or output format. It is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function and followed by a practical use case. There is no redundant or superfluous content.
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 one-parameter listing tool with no annotations or output schema, the description is adequate: it states the scope and provides a use case. It could mention output format or error handling, but the low complexity leaves only a minor gap.
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 fully describes the single parameter 'id' with type and description, achieving 100% schema coverage. The tool description adds no parameter-specific information, so the baseline of 3 is appropriate.
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 lists all tags assigned to a specific candidate, using a specific verb and resource. It distinguishes itself from sibling tools like hires_list_tags, which likely lists all tags in the system.
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 a clear use case (segmentation and audience-based automations) that indicates appropriate contexts. However, it does not explicitly mention when not to use this tool or alternative tools to consider.
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 must carry the behavioral transparency burden. It does disclose the key trait that jobs are 'publicly visible' and supports filtering, but it omits pagination behavior and response details. The schema mentions page/size defaults, but the description itself lacks that nuance.
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 two sentences, front-loaded with the action and resource, and contains no redundant words. Every phrase adds value: scope, filters, and use case.
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?
The description covers purpose, scope, filters, and a concrete use case. There is no output schema, and the description could mention pagination or return structure, but for a simple list tool with well-described schema parameters, it is reasonably 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 100%, so baseline is 3. The description echoes the filter parameters (department, employment type, city, country) but adds no new semantic information beyond what the schema already documents. It is adequate but not compensating for anything missing.
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 opens with a specific verb ('List') and a clear resource ('publicly visible jobs for a company career site'), which precisely differentiates it from internal job tools like hires_list_jobs. It also names the key scope ('publicly visible') and the intended context (career site).
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 explicitly states a use case: 'Use to power a custom careers page.' This gives clear context for when to invoke the tool. However, it does not mention alternatives/exclusions, such as using hires_list_jobs for internal job listings, so it falls short of a 5.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action (list) and resource, but provides no information about response format, pagination, filtering, rate limits, or any potential side effects. For a simple read-only list this may be acceptable, but it is still minimal.
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 two short sentences, each earning its place. It front-loads the core action and then provides use case context. No wasted words or redundant 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 zero-parameter list tool with no annotations and no output schema, the description gives enough context regarding the tool's purpose and intended use. It lacks any mention of return value structure or potential limitations, but given the trivial complexity, it is substantially 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?
The input schema has zero parameters, so the baseline score is 4. The description adds the qualifier "global" which clarifies the scope of the categories, and the mention of taxonomy mapping adds semantic context. There is no need for parameter details since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "List global job categories." It uses a specific verb (list) and a specific resource (job categories), and the phrase "Use for job classification and consistent taxonomy mapping" reinforces the purpose. This effectively distinguishes it from sibling list tools like hires_list_origins or hires_list_tags.
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 usage context with "Use for job classification and consistent taxonomy mapping." It does not explicitly mention alternatives or when not to use it, but the tool's name and the specificity of the resource make the appropriate use case obvious among the many list_* siblings.
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, the description carries the burden of behavioral disclosure. It communicates that this is a read-only list operation with pagination, but does not elaborate on filtering, sorting, default behavior, or the structure of the response. This is adequate but leaves room for more 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 one concise sentence that is front-loaded with the primary action and includes relevant usage context. Every word earns its place with no 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?
For a simple list operation with only two self-explanatory parameters and full schema coverage, the description provides sufficient context. It states the scope and purpose, though it does not describe the return format since no output schema exists.
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 fully describes both parameters (page and size) with clear descriptions, so the baseline is 3. The description adds little beyond referencing 'pagination', which the parameters already imply.
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 uses the specific verb 'List' and identifies the resource as 'partner-accessible companies', clearly distinguishing it from other list_* siblings. The additional context of 'tenant discovery and management panels' clarifies the intended use case.
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 states a clear context for when to use the tool ('tenant discovery and management panels'), which helps the agent choose it. However, it does not explicitly mention when not to use it or name alternative tools for comparison.
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?
Since no annotations are provided, the description carries the burden. It implies a read-only operation via 'List' and scopes to the current company, but it does not disclose pagination behavior, response structure, or potential permissions needed. The 'from_account_id' hint gives some insight into the return contents.
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?
Two sentences with no filler. The core purpose is front-loaded, and the use case is stated succinctly. Every word earns its place.
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 list tool with fully documented parameters and no output schema, the description provides sufficient context. It explains what is listed and why it is used. The reference to from_account_id implies the response includes that field, covering the key return value. Slightly more detail on defaults or response fields would make it complete, but it is 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 input schema already provides descriptions for both page and size (100% coverage), so the description adds no additional parameter-specific meaning. Baseline of 3 is appropriate since the schema handles the documentation.
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 action (list), the resource (mail accounts), and scope (all users in current company). It also provides a specific use case ('resolve from_account_id') that distinguishes it from similar sibling tools like hires_list_user_mail_accounts.
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 gives a concrete scenario ('resolve from_account_id before creating scheduled emails') that tells the agent when to use this tool. It does not explicitly exclude alternatives like hires_list_company_id_mail_accounts, but the 'current company' phrasing narrows the context.
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 must convey behavioral traits. It implies a read-only list operation but does not disclose pagination, ordering, or whether inactive departments are included. The use-case context adds some value, but the description lacks detailed behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and resource, and every word earns its place. No unnecessary detail or repetition.
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 list tool with one optional parameter and no output schema, the description covers the essential purpose and use case. It does not mention potential defaults or response format, but these are not critical for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter company_id, which already explains its meaning and default behavior. The description does not add additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
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 lists departments, a specific resource, and adds context about its use for job organization filters and reporting dimensions. This distinguishes it from sibling list tools like hires_list_origins and hires_list_sources.
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?
Provides an explicit use case ('Use for job organization filters and reporting dimensions'), which helps an agent decide when to invoke this tool. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a list tool.
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, the description carries the full burden. It discloses that the operation is a list (read-only), is paginated, and returns questions. But it does not mention authentication requirements, rate limits, error behavior, or default pagination details. For a simple read-only tool, this is adequate but not rich.
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 two sentences long, front-loaded with the verb 'List,' and every word adds value. It avoids redundancy with the schema and conveys the key behavioral aspects of pagination and inclusion of questions.
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 and the absence of an output schema, the description is sufficient: it explains what is returned, that it is paginated, and that it is scoped to a target company. It does not mention defaults for page/size, but this is not critical for basic use. It could have noted that company_id is optional despite the 'target company' phrasing, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (page, size, company_id) already has a basic description. The tool description adds context by saying 'paginated' and 'target company,' which ties to the parameters, but it does not provide additional format or syntax details beyond what the schema already 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 action ('List') and the resource ('application forms'), and adds specificity with 'paginated' and 'returns forms with their questions for the target company.' This distinguishes it from sibling list tools like hires_list_questions or hires_list_applications.
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 the tool: to list application forms for a specific company, including their questions. It implies pagination via page/size parameters. However, it does not explicitly mention exclusions or alternatives, such as 'use hires_list_questions to list questions separately.'
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, the description carries the full burden for behavioral disclosure. It indicates a read-only operation via 'List' and specifies the scope as 'currently assigned,' but it does not discuss pagination, authentication, or response formats. This is adequate but not rich.
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 two sentences, front-loaded with the purpose, and every word contributes value. The use case sentence is compact and earns its place.
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 one-parameter list tool, the description is sufficiently complete: it states what is listed (users), the scope (job's hiring team), and the intended use cases. It lacks pagination details, but the tool's simplicity and schema coverage make this acceptable.
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 already documents the sole parameter 'id' with 100% coverage, including 'Job ID (numeric) or alias.' The description adds no extra parameter-level information, so the baseline score of 3 applies.
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 opens with a clear verb and resource: 'List users currently assigned to a job's hiring team.' This unambiguously states the tool's function and distinguishes it from sibling tools like hires_add_hiring_team_member, which adds members, and generic list tools.
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 useful context for when to use the tool with 'Useful for notification routing and collaboration tooling.' However, it does not explicitly mention alternatives or exclusion scenarios, so it falls short of a full 5.
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 burden. It communicates that this is a read-only operation ('Get') and describes the core return value, but it does not disclose edge cases such as handling of non-existent jobs, whether unpublished boards are listed, or data freshness. This is adequate but not deeply transparent.
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 two concise sentences, front-loaded with the core action and outcome. It wastes no words and is easy to scan.
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 tool with one parameter and no output schema, the description adequately explains what the tool returns and its intended use cases. It leaves some ambiguity about the exact output format (e.g., board IDs vs. names) but is otherwise 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?
The schema provides 100% coverage for the single `id` parameter, including its description ('Job ID (numeric) or alias'). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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 uses a specific verb ('Get') and resource ('current board publication state for a specific job'), clearly stating what it returns. It distinguishes itself from sibling tools like hires_list_boards by focusing on a specific job's publication state rather than listing all boards.
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 the tool ('distribution dashboards and posting audits') but does not explicitly mention when not to use it or name alternative tools. This is adequate context without exclusions.
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, the description itself must convey safety and behavior. The verb 'List' implies a non-destructive read operation, and the scope is specified, but the description does not disclose any additional behaviors such as pagination, required permissions, or the exact response structure. It is adequate but lacks rich contextual detail.
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: two short sentences, front-loaded with the action and resource. Every word contributes meaning—no filler, no repetition of the tool name, and no unnecessary detail.
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 simplicity of the tool (single parameter, no output schema, no annotations), the description covers the essential purpose and usage context. It could be more complete by mentioning the response format or whether it returns details needed for auditing, but it is not significantly deficient for a basic list operation.
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 already fully describes the only parameter (id) as 'Job ID (numeric) or alias' with 100% coverage. The description adds no further semantic detail about the parameter beyond what the schema provides, so a baseline score of 3 is appropriate.
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 begins with a specific verb ('List'), a clear resource ('webhooks'), and a scope ('job-level events'), which immediately distinguishes it from the sibling 'hires_list_webhooks' (likely all webhooks) and from create/delete webhook tools. It fully states 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use to audit subscriptions and deployment state' provides clear context on when to invoke this tool. It does not explicitly mention alternatives or when not to use it, but the scope is so clearly stated that an agent can infer it is for job-specific webhooks rather than global webhooks.
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 pagination ('Returns paginated discussion notes') and the type of notes ('discussion notes'), but it does not mention read-only nature, authorization requirements, or response structure. This is adequate but not rich.
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 two sentences long, front-loads the core function, and adds a use case in the second sentence. Every word earns its place with no 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?
For a simple list tool with no output schema, the description adequately covers the purpose, pagination, and use case. It doesn't detail the response shape, but that is a minor gap given the straightforward nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter context beyond the schema, but it does link 'candidate_id' to the primary purpose. It doesn't explain 'include' or pagination parameters beyond what the schema already states.
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 lists notes by candidate, using the specific verb 'List' and resource 'notes'. It differentiates from sibling tools like hires_get_note (single note) and hires_create_note (creation), and the phrase 'by candidate' specifies the filtering scope.
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 usage context: 'Use for shared recruiter context and timeline synchronization.' This implies when to use it, but it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
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 bears full responsibility for behavioral disclosure. The description implies a read-only list operation, but lacks details on whether it returns all configured reasons or only active ones, potential pagination, or other behavioral nuances. It is adequate but not rich.
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 two short sentences, immediately front-loaded with the core action and resource. Every clause earns its place, with no redundancy or filler.
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?
The tool is simple with one optional parameter and no output schema. The description covers the purpose and a key use case, making it fairly complete for a list operation. Minor gaps like return format or filtering behavior are offset by the simplicity of the tool and the schema's parameter description.
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 provides a full description of the only parameter (company_id) with 100% coverage, establishing a baseline of 3. The tool description adds no additional parameter context beyond what the schema already states, so the baseline score holds.
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 'List configured rejection reasons for the company', using a specific verb and resource. It distinguishes itself from sibling list tools like hires_list_sources and hires_list_statuses by explicitly naming the resource type. The added phrase 'Use to validate rejection actions and analytics' further clarifies its purpose.
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 phrase 'Use to validate rejection actions and analytics' provides explicit context for when this tool should be invoked, indicating its role in validating rejection actions. However, it does not mention when not to use it or name alternatives, so it falls short of a 5.
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 present, so the description carries the full burden. The verb 'list' implicitly indicates a read-only, non-mutating operation, but the description does not disclose other behavioral traits such as return format, pagination, or scoping details. It adds minimal beyond the action itself.
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 concise at two sentences: 'List candidate sources for the company. Use for attribution sync and reporting consistency.' It front-loads the action and resource, then adds a clear use case without any unnecessary detail.
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 tool with one optional parameter and no output schema, the description adequately covers the purpose and target use. It could mention the return type or that it lists all sources, but the verb 'list' makes the outcome predictable. The use case statement adds useful context for 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 input schema has a single parameter (company_id) with a description that covers its semantics fully (100% schema coverage). The tool description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List candidate sources for the company,' which is a specific verb-resource combination. It clearly identifies the resource (candidate sources) and scope (for the company), making it distinct from other list 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use this tool: 'Use for attribution sync and reporting consistency.' However, it does not mention when not to use it or name alternatives, so it stops short of a full 5.
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, the description carries the burden of behavioral disclosure. It adds useful details about pagination and recommends caching for performance. However, it does not disclose other potential behaviors, such as authentication requirements, rate limits, or the exact structure of the returned tags. This is sufficient for a simple read-only list, but not deeply transparent.
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 three short sentences that each add distinct value: purpose, pagination behavior, and a caching recommendation. No filler words or redundant information. It is well-structured and front-loaded with the core purpose.
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 list tool with one optional parameter and no output schema, the description covers the essential aspects: what it lists, pagination, and a performance tip. The schema provides full parameter details, so the description is complete enough for an agent to select and invoke the tool correctly. It could potentially mention what the tags are used for, but that is inferred from the sibling 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 schema description for company_id is fully detailed ('Target company ID (uses default company when omitted)'), covering all parameter semantics. The tool description adds no additional parameter information. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), the resource ('all tags'), and the scope ('for the company'). This distinguishes it from sibling tools like hires_list_candidate_tags, which focus on candidate-specific tags. The addition of 'Returns paginated results' further clarifies the tool's behavior.
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 the tool: when you need the full set of company-level tags. It implies this is the appropriate tool for tag management UX, especially with the caching recommendation. However, it does not explicitly mention alternatives or exclusions, such as 'for candidate-specific tags, use list_candidate_tags instead.'
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, the description carries the burden for behavioral disclosure. It mentions pagination and the listing behavior, but does not explicitly state that it is a read-only operation or describe any potential side effects, authentication requirements, or constraints like company_id handling. The verb 'List' implies read-only, but more context could be added.
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?
Two sentences, front-loaded with the core purpose, and every sentence provides useful information. There is no filler or repetition.
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?
The description is reasonably complete for a list tool: it states what is listed (placeholders), the pagination aspect, and provides a workflow connection to the prepare tool. Since there is no output schema, it could mention the structure of the returned placeholders, but that is not critical for a list operation. The lack of mention of 'is_notification' or company_id is mitigated by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds a bit of meaning by explaining 'type' as category and 'q' as label search, but this largely repeats the schema. It does not add value for parameters like page, size, or is_notification.
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 'List' and the resource 'available placeholders for email templates', and immediately distinguishes this tool from siblings by mentioning pagination and the related tool 'hires_prepare_template_placeholders'. It is specific and not a tautology.
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 usage guidance by explaining how to use 'type' and 'q' parameters, and explicitly references a sibling tool for the next step (getting an HTML tag). It does not explicitly state when not to use this tool, but the sequential workflow helps differentiate it from alternatives.
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, the description partially carries the burden. It discloses pagination ('Returns paginated results') but doesn't mention authorization needs, whether it's read-only, or the structure of role context. It adds some transparency but lacks depth.
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?
Two sentences, front-loaded with the primary action, and no fluff. Every word earns its place.
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 list tool with no output schema, the description covers purpose, pagination, and use cases. It could mention the need for company_id or what data is returned, but the schema fills in parameter details, making it reasonably 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 coverage is 100% with descriptions for page, size, and company_id, so the baseline is 3. The description adds context about pagination and role context but doesn't enrich the meaning of individual parameters beyond 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 'List users for the target company with role context', using a specific verb and resource. It distinguishes from siblings like hires_get_user (single user) and hires_list_hiring_team (hiring team members) by focusing on all users with roles.
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 context: 'useful for access reviews and hiring-team management', implying when to use it. It doesn't explicitly name alternatives or exclusions, but the use cases help guide selection among list-focused siblings.
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 reveals the key behavioral trait that workflows come with embedded stages, which adds value. However, it omits details such as pagination, filtering, or the default company behavior, which are not disclosed elsewhere. This is adequate for a simple read operation but lacks depth.
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 two sentences long, with the main action front-loaded and the use case following immediately. 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.
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 optional parameter, no output schema—the description is sufficiently complete. It states what the tool returns (workflows with embedded stages) and why to use it (stage-aware integrations and routing rules). Missing details like output structure are not critical for this simple list 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?
The input schema already fully describes the only parameter company_id, including its default behavior when omitted (100% schema coverage). The description does not add any parameter-specific meaning, so the baseline score of 3 applies.
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 uses the specific verb 'List' with the resource 'workflows with embedded stages', clearly distinguishing it from siblings like hires_list_workflow_stages and hires_get_workflow_stages. Adding 'for the company' further scopes the tool's purpose, making it 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 second sentence 'Use to build stage-aware integrations and routing rules' provides explicit usage context, indicating the intended application. However, it does not mention alternative tools or when not to use it, so it falls short of the highest bar.
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 burden. It discloses an important behavioral trait ('Sets boards to activation queue state'), which goes beyond a generic 'publish' claim. However, it does not mention permissions, reversibility, or effects on already-active boards, leaving several operational unknowns.
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?
Two concise, front-loaded sentences convey purpose, state change, and usage context. There is zero fluff; every sentence earns its place.
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 two-parameter tool with no output schema, the description covers what the tool does, the resulting state, and when to use it. It lacks explicit mention of response behavior or edge cases, but the essential context for invocation and selection is present.
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 coverage is 100%, so the schema already documents both parameters. The description adds no new semantic detail about parameters; it only paraphrases 'boards' as 'selected job boards'. Per the baseline rule for high schema coverage, a 3 is appropriate.
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 ('Activate') and the resource ('selected job boards for a job'), and specifies the unique behavior of setting boards to an activation queue state. It distinguishes itself from sibling tools like hires_remove_from_job_board and hires_batch_publish_to_boards by emphasizing 'controlled multi-board publishing workflows'.
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 gives explicit context: 'Use for controlled multi-board publishing workflows.' This implies when to use it versus batch alternatives, though it does not explicitly name alternatives or exclusions. The guidance is clear enough for an agent to select it over batch tools.
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 burden of behavioral disclosure. It does state that the company was previously deleted and is being re-enabled, which is useful, but it omits side effects, permissions required, or behavior if the ID is not a deleted company. Adequate but not rich.
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?
Two compact sentences with no filler. The first sentence states verb and resource, the second gives usage guidance. Every word earns its place.
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?
The tool is simple (one parameter, no output schema) and the description covers both purpose and use scenario. It could mention expected outcome or error conditions, but for a single-id restore action, the description is sufficiently 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?
The schema already documents the only parameter 'id' as 'Company ID' with 100% coverage. The description adds subtle context that the ID should refer to a previously deleted company, but it does not elaborate further. Baseline 3 is appropriate given the schema's completeness.
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 a specific action ('Restore') and resource ('previously deleted company'), and distinguishes it from sibling tools like delete_company by framing it as the inverse operation. The phrase 're-enable it for active use' adds concrete outcome.
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 explicit usage context: 'Use for recovery and rollback scenarios.' This tells the agent when to use the tool, though it does not mention when not to use it or name alternatives. Still, the guidance is clear and actionable.
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 burden of disclosure. It does include the rate limit, which is a useful behavioral constraint, but it omits other potentially relevant details such as authentication requirements, response behavior, or whether submission has any side effects beyond sending the feedback.
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, front-loaded sentence that immediately states the action and scope, then adds the rate-limit constraint. It has zero filler and every word contributes meaningful 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 low complexity of this feedback-submission tool, the description is sufficiently complete: it explains the purpose, mentions the rate limit, and the schema covers all parameters. There is no output schema, but for a simple submit operation the absence of return-value documentation is not a major gap.
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 already provides descriptions for all 5 parameters with 100% coverage, including an enum for issue_type and max-length constraints. The description adds no additional parameter-level semantics, aligning with the baseline score for high 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 tool's function: submitting structured API feedback about missing features, issues, or workflow improvements. The verb 'Submit' and the resource 'structured API feedback' are specific, and this tool is distinct from all sibling tools, which focus on HR data operations.
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 makes it clear that the tool is for submitting feedback and mentions an important constraint: the 5-requests-per-hour rate limit. While it does not explicitly name alternatives, there are no other feedback tools among the siblings, so the usage context is effectively unambiguous.
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, the description discloses a key constraint: the message must be scheduled and not sent. However, it does not explain what happens if the constraint is violated, whether changes are reversible, or what response to expect.
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?
Two concise sentences front-load the purpose and key constraint. Every word earns its place, with no redundant filler.
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 update tool with fully documented parameters, the description provides enough context for selection and invocation. It lacks only minor details like return value or exact error behavior, but no output schema exists to set that expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented. The description adds a little by noting that rescheduling is optional and by summarizing subject/body, but does not go beyond the 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 states a specific action ('Update a scheduled notification email') and resource, clearly distinguishing it from siblings like get/delete/cancel. It also specifies what can be changed: subject, body, and optionally scheduled time.
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 gives clear context: only scheduled, not-yet-sent messages can be updated. This tells when the tool is applicable and implies exclusion of already-sent messages, though it does not name an alternative for those cases.
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 object ownership verification ('strictly verified against the authenticated API key's company'), file size and type limits for voicemail, and the return shape `{uuid, url, file, relative_time}`. It does not cover failure modes or rate limits, but adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening sentence and a dense but organized category breakdown. It packs a lot of information into two sentences without being verbose, though the first sentence is long. Front-loaded purpose makes it easy to scan.
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?
The tool handles many categories and has a nested file object, but the description covers all key aspects: return format, category-specific rules, ownership verification, and special voicemail behavior. There is no output schema, so the described return value is essential. Minor gaps include error handling and size limits for non-voicemail categories.
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 schema already describes all parameters (100% coverage), so the baseline is 3. The description adds value by clarifying per-category object_id semantics (omit for voicemail), the default behavior of company_id (defaults to authenticated company), and the specific voicemail size/type 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 tool's purpose: 'Upload a file and create an attachment.' It lists supported categories, making the resource scope explicit. However, it does not explicitly differentiate from sibling tools like hires_upload_application_attachment, which could cause ambiguity.
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 each category, including when to omit object_id (voicemail) and how the returned uuid is used (nurture voicemail steps). It does not mention alternative tools or when not to use this tool, but the category breakdown gives strong usage guidance.
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 burden of behavioral disclosure. It implies a read-only operation through 'Get' and adds the contextual hint about ownership-sensitive actions, but it does not explicitly confirm no mutations, discuss permissions, rate limits, or return format. This is adequate but not rich.
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?
Two short, front-loaded sentences deliver the purpose and usage guidance without wasted words. Every sentence adds value.
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 simple single-parameter read tool with no output schema, the description sufficiently explains what is returned (company profile and owner metadata) and when it should be used. No additional complexity requires more detail.
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 fully documents the single 'id' parameter with the description 'Company ID', providing 100% schema coverage. The tool description adds no parameter-specific meaning, so the baseline of 3 applies.
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 uses a specific verb ('Get') with a clear resource ('company profile and owner metadata'). It distinguishes this from sibling tools like list, create, update, and delete company tools by focusing on retrieval of profile and owner metadata.
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 explicitly states when to use the tool: 'Use before updates or ownership-sensitive actions.' It provides clear context but does not mention when not to use it or name alternative tools, though the sibling list makes alternatives inferable.
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 burden of disclosing behavior. It does state the return payload (evaluator info, summary score, summary text, and individual answers), which is helpful, but it does not explicitly mention that it is a read-only operation or cover potential edge cases, such as behavior when the evaluation is incomplete.
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 two sentences: the first defines the core function, the second lists return contents and a usage scenario. Every sentence adds value, with no redundancy or extraneous information.
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 simple one-parameter input, no output schema, and no annotations, the description sufficiently covers what the tool returns and when to use it. It provides enough context for an agent to select it appropriately without further documentation.
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 only parameter (id) is fully described in the schema as 'Evaluation form ID', so schema coverage is 100%. The description adds no further semantic detail about the id, such as format or where to obtain it, so it relies entirely on the schema for parameter meaning.
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 retrieves a filled evaluation form with all answers, specifying the resource (evaluation form) and the action (get). It also lists the return contents, distinguishing it from listing tools or other getters like hires_get_form.
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 by stating 'Use for detailed review of evaluator feedback on a candidate application.' This implies it is for detailed inspection rather than simple listing, but it does not explicitly name alternative tools or state when not to use it, so it misses the top score.
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, the description carries the full burden. It adds valuable behavioral details: each entry contains a download URL requiring Bearer auth, relative time, file metadata, and a type field. It does not mention pagination or empty results, but the auth hint and field breakdown offer meaningful transparency beyond the tool name.
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, dense sentence that front-loads the core action and then enumerates the return fields with no wasted words. Every clause adds relevant information.
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 one-parameter read/list tool with no output schema, the description sufficiently details the response structure (uuid, download URL, relative_time, metadata, type) and auth requirements. It is complete for the tool's simplicity and likely 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 input schema already fully describes the only parameter ('Candidate ID (integer) or alias (string)'), so schema coverage is 100%. The description adds no supplementary parameter details, placing it at the baseline of 3.
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 action ('List') and the resource ('files attached to a candidate'), with specific detail on what constitutes 'files' (resumes and other documents). It distinguishes itself from sibling tools like hires_list_application_attachments and hires_get_candidate_resume by focusing on candidate-level files.
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 usage is implied: use when you need all files for a candidate. However, it does not explicitly mention when not to use or draw comparisons to alternatives, such as when to use hires_get_candidate_resume for just the resume or hires_list_application_attachments for application-level files. Absence of exclusions but clear context keeps it at 'implied usage'.
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. 'List' implies a read-only operation, and 'taxonomy values' clarifies the output, but it does not explicitly state side effects (none) or return format. Minimal but adequate for a simple list 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 two concise sentences. The first states the function, the second provides usage context. No redundant information or filler.
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 low complexity (0 parameters, no output schema), the description is complete. It explains what is listed and why it is useful, covering all necessary context for an agent to select and invoke the 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 tool has 0 parameters, so schema coverage is 100% by default. The description adds no parameter details, but the baseline for 0 parameters is 4, and no compensation is needed.
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 uses the specific verb 'List' with the resource 'education level taxonomy values', clearly identifying what the tool does and distinguishing it from sibling taxonomy tools like experience levels or origins. The note about being useful for job requirements adds clarity.
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 states it is 'useful for job requirements and structured matching', providing a clear use context. However, it does not explicitly compare to alternatives or mention when not to use it, so the guidance is implied rather than explicit.
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 for behavioral disclosure. It explicitly reveals two key side effects: creating a candidate record and triggering the career-site pipeline automation. This goes beyond the basic 'submit' action and informs the agent about important write operations and downstream effects, though it doesn't mention permissions, idempotency, or response 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 two sentences long, front-loaded with the primary action, and includes only essential information about side effects. No unnecessary words or repetition of schema details.
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 10 parameters and nested objects, no output schema, and no annotations, the description adequately states purpose and key side effects but lacks guidance on expected return values, error conditions, or what happens on duplicate applications. It is sufficient for basic use but not fully complete for a complex mutation 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 100%, so the baseline is 3 even with no parameter details in the description. The description does not add meaningful semantics beyond the schema, but it does imply that first_name, last_name, email, and other core fields are used to create the candidate record. No extra information is provided that would raise the score.
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 'Submit' and the resource 'job application on behalf of a candidate,' distinguishing it from related tools such as hires_create_application and hires_create_candidate. Mention of the career-site pipeline automation further differentiates it from internal application creation tools.
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 gives clear context that this tool is for submitting applications via the career-site pipeline, implying use for outward-facing applications rather than internal ones. While it doesn't explicitly name alternatives or exclusions, the phrase 'career-site pipeline automation' provides enough context for when to use this tool versus siblings like hires_create_application.
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 burden of behavioral disclosure. It discloses the core behavior: advancing an application to the next pipeline stage automatically, and adds the useful detail that no stage_id is required. However, it does not mention edge cases such as what happens if the application is already at the final stage, or any side effects, so transparency is moderate.
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: two sentences with no unnecessary words. The first sentence states the action, and the second clarifies the automatic stage determination. Information is front-loaded and every word earns its place.
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 tool with only two parameters and no output schema, the description is sufficiently complete. It explains what the tool does and the key input behavior (no stage_id). It does not describe return values, but since there is no output schema, that is not strictly required. It could mention potential error cases, but overall it's adequate for an AI agent to select and invoke 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?
Schema coverage is 100%, so the parameter descriptions already cover 'id' and 'include'. The description adds semantic value by explicitly stating that no stage_id is needed, which clarifies that only the application 'id' is required for the tool to operate. This goes beyond the schema's mere listing of parameters and helps the agent understand the automatic behavior.
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 uses a specific verb 'advance' and resource 'application', and clarifies it moves to the next pipeline stage automatically. This clearly distinguishes it from sibling tools like 'move_application' or 'transfer_application' that likely involve specifying a target stage or changing jobs.
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 explicitly states 'No stage_id needed -- the system determines the next stage automatically,' providing clear context for when to use this tool (i.e., when you want to advance by one stage without specifying a target). It implies that for specifying a particular stage, a different tool would be needed, though it does not explicitly name an alternative.
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 and discloses a key behavioral trait: "Returns per-item results with partial success support." This tells the agent that failures on some items do not fail the entire request, which is crucial for handling batch operations. It also repeats the max 100 constraint, adding practical 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?
Two concise sentences with no filler. The first sentence front-loads the core action and scope, and the second adds key return/error behavior. Every word earns its place.
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 (2 params, no output schema), the description is complete enough. It explains the batch scope, the limit, and the partial success return behavior, which are the main contextual needs. The only minor gap is not specifying the exact structure of per-item results, but that is acceptable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters fully (Candidate IDs and Tag names), with 100% coverage. The description adds no additional parameter semantics beyond restating the max 100 limit for ids, which is already in the schema. Baseline 3 is appropriate since schema does the heavy lifting.
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 a specific verb and resource: "Remove tags from multiple candidates in one request." It also distinguishes itself from siblings like hires_remove_candidate_tag by emphasizing the batch/multiple-candidate scope and the max limit of 100.
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 phrase "in one request (max 100)" strongly implies this is for batch operations across multiple candidates, differentiating it from the singular hires_remove_candidate_tag. While it doesn't explicitly name alternatives or state when not to use it, the batch focus gives clear contextual guidance.
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 must disclose side effects and nuances. It does disclose that placeholders require a multi-step preparation process, and that subject and body support placeholders. However, it does not mention required permissions, idempotency, duplicate name handling, or what the API returns upon creation. The description also confusingly says placeholders like {{first_name}} are supported but then instructs to get an HTML tag from prepare, leaving ambiguity about the exact placeholder syntax.
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 three sentences: a clear purpose statement, a note about placeholder support, and a numbered list for the placeholder workflow. It is front-loaded with the main action first, and every sentence contributes useful information without padding.
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?
The tool has 4 parameters with full schema coverage and no output schema. The description covers the main purpose and the trickiest aspect (placeholder embedding), but omits details about the created object's return value, whether company_id is optional or required for multi-tenant scenarios, and edge cases like duplicate names. Given the simplicity of a create operation, it is reasonably complete but not exhaustive.
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 descriptions cover all 4 parameters, so the baseline is 3. The description adds value beyond the schema by explaining that subject and body support placeholders and by giving a workflow to generate the correct HTML tag. It does not add meaning for name or company_id, but the existing schema descriptions are adequate.
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?
Clearly states it 'Create a new email template with name, subject, and body'. This is a specific verb (create) plus resource (email template), distinguishing it from sibling tools like update_email_template and delete_email_template. It also mentions the key feature of placeholder support.
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?
Provides explicit usage instructions for embedding placeholders, referencing GET /template-placeholders and POST /template-placeholders/prepare as required preliminary steps. This gives the agent a concrete workflow for a common task, and implicitly indicates that placeholders require two additional calls before insertion. However, it does not explicitly contrast with update/list/delete tools, though the create semantics are clear from the name.
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 burden of behavioral disclosure. It states the core action and a limitation (cannot cancel sent messages), but does not mention reversibility, side effects, permissions, or error conditions. The description is functional but lacks depth expected for a mutating operation without 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 two concise sentences, front-loaded with the verb 'Cancel'. Every word earns its place, with no redundancy or filler. It is a model of efficiency.
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 simplicity (one parameter, no output schema, no nested objects), the description sufficiently covers the tool's purpose and key limitation. It does not explain the return value or response behavior, but for a cancel/delete operation, this is often implicit. The description is adequate for a straightforward 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?
The schema already provides 100% coverage with a clear description for the only parameter ('Notification email message ID'). The tool description adds no additional meaning beyond what the schema states, so the baseline of 3 is appropriate.
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 uses a specific verb ('Cancel') and resource ('scheduled notification email'), clearly distinguishing it from general message deletion tools. The scope is well-defined: only scheduled emails before being sent. This is more precise than typical descriptions and differentiates from siblings like delete_message.
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 when to use (before the email is sent) and when-not (already sent messages cannot be canceled). This is a clear exclusion that helps the agent decide between this tool and others. While alternatives are not named, the boundary is unambiguous.
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 disclosing behavioral traits. It discloses that the delete is a soft-delete and that active executions will be stopped, which are important side effects. It could further detail reversibility or permissions, but the disclosed traits are highly relevant and non-obvious.
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 two concise sentences, front-loading the action ('Delete') and immediately clarifying the key qualifier ('soft-delete'). It then adds one important behavioral detail. No redundant words or repetition of schema data.
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 delete tool with one parameter and no output schema, the description covers the essential context: the soft-delete nature and the impact on active executions. It could mention error handling or idempotency, but given the tool's low complexity, the description is adequately 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?
The input schema already provides 100% coverage, describing 'id' as 'Nurture campaign ID'. The description adds no additional parameter meaning, but given the schema is self-sufficient, the baseline of 3 is appropriate.
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 states the verb 'Delete' and resource 'nurture campaign' clearly, and distinguishes it from other nurture campaign tools by specifying 'soft-delete' and the effect on active executions. This is a specific and unambiguous purpose that differentiates it from get/update/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 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 delete a nurture campaign) and adds behavioral guidance by noting that active executions will be stopped. It does not explicitly mention alternatives or exclusions, but the context is sufficient for a delete operation.
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, the description carries the transparency burden. It discloses the 404 behavior for non-public jobs and lists the extended fields returned, providing meaningful behavioral context for a read-only tool. It doesn't cover auth or response shape, but the key edge case is addressed.
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 short sentences, front-loaded with the action, no redundant information. Every sentence adds value: what it does, what it returns, and a key error condition.
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 get-by-ID tool with two parameters and no output schema, the description covers purpose, return contents, and error behavior. It's nearly complete but doesn't specify exact response structure or authentication requirements, which are likely public and self-explanatory.
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 covers 100% of parameters with descriptions for id and company_slug. The description adds no new semantic information beyond reinforcing that the job is fetched by ID and the career site is identified by company_slug, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with 'Get full details of a single public job by ID', clearly stating the verb (Get), resource (public job), and identification method (by ID). It also lists extended fields and 404 condition, distinguishing it from sibling tools like hires_get_job, which likely targets internal jobs.
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?
Description implies usage for public job details and explicitly states it returns 404 for draft, archived, or internal jobs, providing clear when-not context. However, it does not name an alternative tool (e.g., hires_get_job) for internal jobs, so it falls short of a 5.
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. It implicitly conveys read-only behavior via 'Get' and specifies the returned content (form details + questions with statuses). It does not explicitly state that it does not mutate data, but this is strongly implied by the verb. It adds useful detail beyond the name.
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, front-loaded sentence that states the operation and key details ('Get form details including all questions with their statuses'). Every word earns its place; there is no filler or repetition.
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 getter with one parameter and no output schema, the description adequately explains the return value (form details with questions and statuses). It does not explicitly state the operation is read-only, but the verb 'get' implies it. It is complete enough for the tool's simplicity.
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 only parameter 'id' is fully described in the schema ('Form ID'), providing 100% coverage. The tool description does not add additional parameter meaning, but the baseline for high schema coverage is 3, and the description's reference to 'form details' aligns with the 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 uses a specific verb ('Get') and resource ('form details'), and adds a distinguishing detail ('including all questions with their statuses'). This clearly sets it apart from sibling tools like hires_list_forms (list vs. get) and hires_get_question (single question vs. form with all questions).
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 context is clear: use this to retrieve a single form's details, including its questions and their statuses. However, it does not explicitly mention when not to use it or point to alternatives (e.g., hires_list_forms for a list of forms), so it falls short of a 5 but provides unambiguous 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, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the basic 'get by ID' by noting the tenant scope constraint and the practical usage of `default_mail_account_id` as `from_account_id`. It does not elaborate on error cases or permissions, but the extra details provide meaningful 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?
Two concise sentences with no fluff. The first sentence promptly states the purpose, and the second provides actionable additional guidance. Every word contributes meaning, making it efficiently front-loaded and well-structured.
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?
The tool is simple with one input parameter and no output schema, so the description is largely sufficient. It covers the action, usage scenario, tenant scoping, and a useful note about the response field. It could mention the return type or behavior when not found, but for a simple getter, the description is fairly 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?
The input schema already has 100% coverage with a description for the sole parameter `id` ('User ID'). The tool description does not add any further meaning to the input parameter itself. It does mention a field from the response (`default_mail_account_id`), which relates to output rather than input, so parameter semantics remain at the baseline.
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 action: 'Get a single user by ID' within tenant scope. It distinguishes from sibling tools like hires_get_candidate by specifying 'user' and from list tools like hires_list_users by emphasizing 'single user by ID'. The verb+resource 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: 'Use for identity resolution in automation flows.' This tells the agent when to apply it. However, it does not explicitly mention exclusions or alternative tools (e.g., when to use list_users instead), so it stops short of a full 5.
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 burden of behavioral disclosure. It notes that the tool lists applications across 'all accessible jobs' and supports filtering, but it doesn't mention pagination behavior, default sorting, or response structure. The absence of any warning about side effects is appropriate for a read-only endpoint, but deeper details are left to 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the core action front-loaded and no redundant phrasing. Every clause adds value: scope, filter capabilities, and use cases.
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 tool with 13 optional parameters and no output schema, the description gives a clear high-level overview and practical use cases, but it does not mention the include parameter for embedding relations or pagination defaults. The schema fills most gaps, and the description is sufficient for an agent to decide when to use it, though not exhaustive.
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 schema already provides descriptions for all 13 parameters (100% coverage), so the baseline is 3. The description adds a compact summary of filter dimensions ('candidate, job, stage, status, AI score range, and date ranges'), which helps the agent quickly map natural-language requests to parameter groups. This elevates it above baseline.
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 opens with 'List applications across all accessible jobs,' which provides a specific verb (list), resource (applications), and scope (all accessible jobs). This clearly distinguishes it from sibling tools like hires_get_application (single application) and mutation tools like hires_create_application.
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?
It explicitly states 'Use for pipeline analytics, sync jobs, and ATS dashboards,' giving concrete contexts for when to invoke this tool. It doesn't mention alternatives or exclusions, but the use cases are clear enough to guide 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 discloses that the tool lists supported employment types and gives examples, but it does not specify the exact return format (strings, objects, etc.) or whether the list is static or exhaustive. This is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two short sentences that immediately state the action and purpose. Every word earns its place, with no redundancy or filler.
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 (no parameters, no output schema, no annotations), the description covers the essential function and its intended use case. It could mention the return structure, but for a parameterless enumeration, the description is sufficiently complete for an agent to understand what the tool does and when to use it.
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 zero parameters, and the input schema is empty. According to the rubric, a baseline of 4 applies for 0-parameter tools, and the description correctly adds no unnecessary parameter information since none exist.
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 uses the specific verb 'List' with a clear resource ('supported employment types') and provides concrete examples (full-time, part-time, contract, etc.). This clearly distinguishes it from sibling list tools like hires_list_origins or hires_list_sources by specifying the exact domain it covers.
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?
Explicitly states 'Use for validation and normalization,' giving clear context for when this tool should be invoked. It does not mention alternatives or exclusions, but the instruction is sufficiently distinct and useful for the intended use case.
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 explicitly states that it returns 'outbound messages only (sent and scheduled), not received,' which is a key behavioral trait. It also hints at use cases (pending queue, delivery history) that inform the agent about the data's nature. However, it does not mention pagination limits or response structure, but these are partially covered by the schema 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 two sentences, front-loaded with the primary action and scope. It is concise with no filler, and the second sentence adds practical usage context without unnecessary detail.
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 there is no output schema and no annotations, the description does a good job indicating what the tool returns (outbound messages) and the context (cold outreach monitoring). It does not explain the response format, but for a list operation with well-described parameters, this is sufficient. The description covers the key aspects of what and why, making it complete enough for most use cases.
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 100% parameter description coverage, so the baseline is 3. The description adds no extra semantic meaning beyond what the parameter descriptions already provide. It references the 'mail account' concept, aligning with from_account_id, but does not enhance understanding of pagination or filters beyond the 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 function: 'List messages sent or scheduled from a specific mail account.' It specifies the resource (messages), the action (list), and the scope (outbound from a mail account), which distinguishes it from sibling tools like hires_list_candidate_messages that likely focus on candidate-specific messages.
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 practical context: 'Useful for monitoring cold outreach campaigns — check pending queue, delivery history, and plan next sends.' This implies when to use the tool, though it does not explicitly mention alternatives or exclusions. The use case is clear enough for an agent to decide when this tool is appropriate.
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 burden of disclosure. It implies a read-only listing operation and provides useful context that the values should be cached for validation. However, it doesn't explicitly state that the tool is safe/non-mutating or whether the list is exhaustive beyond the examples, leaving some ambiguity.
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?
Two sentences, no fluff. The first sentence defines the resource, and the second provides a practical tip. Every word earns its place.
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 list tool with no parameters and no output schema, the description is sufficiently complete. It names the specific values and hints at a common use case. Slight ambiguity about whether the list is exhaustive or if there are caveats, but overall it's adequate.
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 zero parameters and the schema is empty, so there is nothing to explain. The description adds value by enumerating the actual status labels, which compensates for the lack of parameter details. Baseline for 0 params is 4.
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 job status labels' followed by specific examples (draft, published, on_hold, closed, archived). This distinguishes it from sibling tools like hires_list_origins or hires_list_sources, which list different reference data.
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 instruction 'Cache to validate job status updates' gives a concrete use case: when setting or updating job status, use this cached list to ensure the new status is valid. This implies when to use the tool (for status validation) and is clear enough, though it doesn't explicitly list exclusions compared to alternatives.
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 the full burden. 'List' clearly indicates a read-only operation with no side effects, which is an important behavioral disclosure. However, it does not mention pagination, ordering, or the exact nature of return values, but for a simple list operation this is adequate.
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, concise sentence that front-loads the action ('List') and includes the essential scope. No unnecessary words or repetition.
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 list tool with one well-documented parameter and no output schema, the description is nearly complete. It clearly states the resource and scope, which is sufficient for the agent to select and invoke the tool correctly. It falls short only in not mentioning potential nuances like pagination or response details, but these are not critical for basic 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 input schema already provides full coverage (100%) with the parameter 'id' described as 'Company ID.' The description adds no further meaning about the parameter, so it does not exceed the baseline provided by the 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 uses the specific verb 'List' with the resource 'webhook subscriptions' and clearly specifies the scope as 'at company scope.' This distinguishes it from sibling tools like hires_list_job_webhooks, which would be at the job level.
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 clearly conveys that this tool is for company-scoped webhooks, implying it should be used for company-level configuration rather than job-level. It does not explicitly name alternative tools or provide exclusion criteria, but the scope information gives sufficient context for when to use it.
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 the full transparency burden. It discloses the important patch-like behavior: 'Only provided fields are overwritten; omitted fields keep their current values.' It also clarifies placeholder handling, which is useful behavioral context beyond the schema. It does not discuss authentication, errors, or side effects, but for a simple update this is acceptable.
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?
Two sentences, front-loaded with purpose, then behavioral details. Every sentence earns its place with no filler.
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 low-complexity update tool with a fully documented schema and no output schema, the description covers the key partial-update semantics and placeholder guidance. It could mention response behavior, but that is not mandatory given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all four parameters with 100% description coverage, so the baseline is 3. The description adds no new per-parameter detail beyond the placeholder workflow, which is already reflected in the schema's field descriptions.
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 opens with a clear verb and resource: 'Update an existing email template.' It explicitly states 'existing' to distinguish from creation, and the operation is clearly different from list/get/delete siblings.
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 states the partial-update behavior and says 'To add placeholders, use the same workflow as creation,' which guides the user toward the creation workflow for that task. It could be more explicit about using create_email_template for new templates, but the update-vs-create distinction is clear.
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 discloses a key side-effect (does not create a new timeline item) and implies partial update semantics via 'and/or.' It does not cover permission requirements, idempotency, or return values, but for a simple update tool this is a reasonable amount of 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 two concise sentences, front-loaded with the action and key constraint, and contains no filler. Every word contributes to understanding.
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 4-parameter update tool with no output schema, the description covers purpose, usage context, and a critical behavioral distinction. It could mention return value or permissions, but overall it is sufficiently complete for effective agent 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description mentions 'body and/or visibility' which maps to two parameters, but adds no additional detail beyond the schema. Baseline 3 is appropriate.
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 action ('Update note body and/or visibility') and the specific resource ('note'), while distinguishing from sibling tools by noting it does not create a new timeline item. This is a specific verb+resource with clear scope.
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 explicitly says 'Use for corrections and moderation workflows,' giving clear when-to-use guidance. It also implies an alternative by mentioning 'without creating a new timeline item,' which contrasts with create_note, but does not name the alternative explicitly.
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 present, so the description carries the burden of behavioral disclosure. It discloses key behaviors: returns per-item results, supports partial success, and enforces a max request size. It does not discuss permissions or reversibility, but for a batch mutation tool, the disclosed behavior is substantial.
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 two concise sentences, front-loading the core purpose and adding the most relevant behavioral details. Every sentence adds value with no redundancy or filler.
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 simple parameter set and the inclusion of per-item result behavior, the description sufficiently covers what an agent needs to select and invoke the tool correctly. No output schema is present, but the description outlines the response shape enough for initial understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (ids with max 100, optional rejection_reason_id). The description largely restates this information, adding no new parameter-level semantics beyond what the schema already states.
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 uses a specific verb ('Reject') and resource ('applications'), and clearly indicates the batch scope ('multiple applications in one request'). This distinguishes it from the sibling single-reject tool and other batch operations.
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 phrase 'Reject multiple applications in one request' clearly implies the intended use case for batch rejection. It also includes a practical constraint (max 100 IDs) but does not explicitly mention alternatives like the single-application reject tool.
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, the description carries the full behavioral burden. It discloses a key edge case (returns null if not AI-scored) and describes the response components. It does not explicitly state read-only semantics, authentication needs, or error conditions, but 'get' implies read-only and the null behavior adds meaningful insight.
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?
Two concise sentences that front-load the main purpose and add a critical behavioral note. No redundant information or filler.
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 simple, single-parameter getter with no output schema, the description adequately explains what the tool returns (per-criterion scores, justifications, follow-up questions) and the null fallback case. It covers the essential behavior without unnecessary detail.
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 coverage is 100% for the single parameter (id) with description 'Application ID.' The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a structured AI score for an application, listing specific components (per-criterion scores, justifications, follow-up questions). It distinguishes itself from general application getters like hires_get_application by focusing on the AI score specifically.
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?
Provides clear context: use this to get the AI score of an application. The null-score note implies the tool is for applications that have been AI-scored, but it does not explicitly mention alternatives or when not to use it. Lacks explicit exclusions but the purpose is evident.
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?
Without annotations, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'Get' by specifying the exact return fields ('subject, body, sender, recipient, and schedule metadata'), which clarifies what the agent can expect. It does not explicitly state read-only behavior, but 'Get' strongly implies a non-mutating 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 concise and well-structured: two sentences, front-loaded with the action, and every clause adds value. It avoids redundancy and does not repeat the schema's parameter description.
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 simplicity (1 parameter, no output schema), the description is complete. It states the purpose, enumerates the return fields, and provides a hint for discovering valid IDs. This is sufficient for an agent to invoke the tool correctly without additional information.
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 already provides 100% coverage of the single parameter 'id' with its description 'Notification email message ID.' The tool description adds minimal semantic value beyond the schema, mainly by giving an example and pointing to the candidate messages list for ID discovery. This aligns with the baseline for full 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 tool's function: 'Get a notification email message (e.g. rejection email) by ID.' It identifies the specific resource type ('notification email message') and differentiates from sibling tools like 'get_message' by using the term 'notification'. The example and return-value summary further clarify the purpose.
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 actionable guidance by telling the agent to use the candidate messages list to discover notification message IDs. While it does not explicitly say when not to use this tool, the retrieval-by-ID pattern is self-evident and the hint directs the user to the appropriate list endpoint.
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. 'List' implies a read-only operation, but the description does not disclose details like response format, pagination, or authentication requirements. For a simple taxonomy list, it is minimally sufficient but lacks richer 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 two short sentences, front-loaded with the primary action ('List candidate origin taxonomy values') followed by a targeted use case. Every word earns its place with no redundancy.
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 zero-parameter list tool, the description covers what it does and why to use it. Without an output schema, it could mention return type, but the pragmatic use case ('attribution analytics and source normalization') makes it sufficiently complete for an agent to select and invoke 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 tool has zero parameters, so the baseline is 4. The description correctly adds no parameter-level detail beyond what the empty schema already conveys, which is appropriate.
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 'lists candidate origin taxonomy values' with a specific resource (candidate origin) and a clear verb. It distinguishes itself from sibling list tools by mentioning 'attribution analytics and source normalization', which clarifies its unique scope.
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 it: 'Use for attribution analytics and source normalization.' It does not explicitly list alternatives or exclusions, but the use case is specific enough to guide an agent away from similar list tools.
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, the description carries the burden of behavioral disclosure. 'List' clearly implies a read-only operation, but no explicit statement about non-mutation, auth requirements, pagination, or return format is given. For a simple no-parameter list, this is adequate but not richly transparent.
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 two sentences: the first states the action and object, the second gives the use case. Every word earns its place; no fluff or redundancy.
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 simplicity (zero parameters, no output schema, clearly scoped metadata listing), the description is complete: it identifies what is listed, who it is for (platform support), and a motivating use case.
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 zero parameters, and the schema coverage is 100% (the schema is empty). Baseline for 0 params is 4, and the description adds relevant context about what is listed without needing to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('available question types supported by the platform'). It also distinguishes itself from sibling tools like hires_list_questions, which lists questions rather than question types, and from form-related tools that operate on forms 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?
It explicitly states the intended use case: 'Use to drive dynamic form builders.' This gives clear when-to-use context. However, it does not mention alternatives or situations when the tool should not be used, falling short of a full 5.
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 the full burden. It transparently discloses the key state changes: status becomes active and rejected_at is cleared. However, it does not mention permissions, error conditions, or potential side effects (e.g., notifications), leaving minor 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 concise and front-loaded with the action, using two short sentences that contain no extraneous information. It directly states what the tool does and the resulting state change.
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 simple state-reversal tool with only 2 parameters, full schema coverage, and no output schema, the description is complete enough. It explains both the purpose and the exact state changes, which is sufficient for correct 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?
The input schema covers 100% of parameters with descriptions (id: 'Application ID', include: 'Comma-separated relations...'). The description adds no additional parameter-level semantics beyond this, so the baseline score of 3 for high schema coverage is appropriate.
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 action: 'Undo a rejection and reopen a previously rejected application.' It uses a specific verb ('Undo') and resource ('rejection'), and distinguishes it from siblings like hires_reject_application. It also explains the exact outcome: 'status returns to active and rejected_at is cleared.'
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 implies usage for previously rejected applications by specifying 'previously rejected application', which gives clear context. However, it does not explicitly mention alternatives or when-not-to-use cases, such as 'use hires_reject_application for rejecting' or 'do not use for active applications', so it falls short of explicit exclusions.
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 burden of disclosing behavior. It clearly indicates a read-only operation ('Get') and provides useful context that this is a prerequisite check for paid features. It does not detail error handling or return format, but for a simple flag getter this is reasonable.
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?
Two short sentences with no waste. The first states the action and resource, the second gives usage guidance. Information is front-loaded and every sentence earns its place.
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?
The tool is very simple (no params, no output schema). The description explains what it does and when to use it, making it essentially complete. A slight gap is the lack of detail on returned flags, but that is not critical for invocation.
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 is an empty object. The baseline for 0 params is 4, and the description adds no param info (not needed).
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 uses a specific verb ('Get') and resource ('billing/pricing capability flags for the current company'), clearly distinguishing this tool from all sibling tools, none of which mention billing or pricing.
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 explicitly states when to use this tool: 'Use before invoking paid-only API behaviors.' This provides clear context, though it does not mention alternatives or exclusions (which are unnecessary given the tool's unique purpose).
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?
Despite no annotations, the description discloses key behavioral traits: updates require passing the full step list, removals are handled via is_deleted=true, and existing steps must include ids. This exposes the full-replacement semantics that are critical for correct invocation, though it omits mention of return values or permission requirements.
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 three short sentences, front-loaded with the action, and each sentence adds crucial information without redundancy. It's a model of efficient specification.
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 (11 parameters, various step types) and the absence of annotations or output schema, the description covers the most important usage constraint (full step list with is_deleted flag) but leaves the return value unmentioned. The rich schema compensates for parameter details, making it adequately 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?
Schema description coverage is 100%, so a baseline of 3 applies. The description adds valuable context beyond the schema by emphasizing that all steps must be passed and that removal uses is_deleted, which clarifies the array semantics more forcefully than the schema's generic description.
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 uses a specific verb ('Update') with a clear resource ('existing nurture campaign'), distinguishing it from sibling tools like hires_create_nurture_campaign and hires_delete_nurture_campaign. The phrase 'existing' further clarifies its scope.
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?
It states clearly to use the tool when updating an existing nurture campaign, providing context for when to call it. It also gives operational guidance on the required update pattern (pass all steps, mark deleted steps) but doesn't explicitly name alternatives or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does it well. It discloses that already-sent notifications are unaffected and that the operation returns success even when no scheduled notifications exist, providing valuable idempotency and scope information.
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 compact and front-loaded: it starts with the core action, then clarifies non-effects and edge-case behavior. Every sentence contributes meaning with no redundancy.
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 a single parameter, no output schema, and no annotations, the description is complete. It covers the action, scope, side-effect boundaries, and response behavior, making it fully understandable in 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 already fully describes the single candidate_id parameter with 100% coverage. The description adds no extra detail about the parameter, so the baseline of 3 applies.
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 specifies a precise action ('Cancel all scheduled notification emails') with a clear target ('for a candidate'). It distinguishes itself from sibling tools like delete_notification_message by focusing on the 'all scheduled' bulk cancellation scope.
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 implies when to use this tool: when you need to cancel all scheduled notification emails for a candidate. It does not explicitly mention alternatives or when not to use it, but the scope is clear enough to prevent confusion with singular delete or update operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses key behaviors: the URL must belong to the configured API host, other hosts are rejected to prevent Bearer token leakage, the response contains file_name, mime_type, size, and base64-encoded data, and files over 25 MB are rejected up-front without memory loading. This covers security, return format, and size limits.
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 packs substantial detail into two sentences with no filler. It front-loads the main action, provides examples, and states constraints and return format in an organized manner. Every sentence earns its place.
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?
With no output schema and no annotations, the description alone must explain the return format and edge cases. It does this thoroughly: returns {file_name, mime_type, size, data}, base64 encoding, size limit, and host restriction. For a single-parameter tool, this is 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 coverage for the single 'url' parameter is 100%, and the schema already includes a detailed description with an example URL. The tool description adds the security rationale about host matching but does not introduce new parameter semantics beyond what the schema provides. Baseline 3 applies.
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 begins with the specific verb 'Download an attachment' and enumerates the exact resource types (resume, candidate file, application file, mail attachment, call recording). It clearly distinguishes this download tool from upload/list siblings like hires_upload_attachment and hires_list_application_attachments.
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 explicitly states the tool expects an absolute URL returned by another endpoint, which tells the agent when to use it. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough. A brief exclusion (e.g., 'for uploading use hires_upload_attachment') would push this to 5.
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, the description carries the full burden of behavioral disclosure. It details the return fields (uuid, absolute download URL, relative_time, file metadata, type), notes Bearer authentication for the URL, and explains the effect of include='text_content'. It doesn't mention potential errors or absence of a resume, but for a GET operation this is solid.
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 two sentences: the first states the main action and return fields, the second explains the optional parameter. It is front-loaded, without unnecessary words or repetition of schema details.
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?
There is no output schema, so the description must explain return values, which it does thoroughly. It covers the main resource, return fields, auth requirement, and optional behavior. For a tool with only 2 parameters, this is sufficiently 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?
Schema coverage is 100%, so both id and include are already described. The description adds extra meaning by explaining the effect of include='text_content' (adds a `text` field without downloading) and clarifies the return structure. This goes beyond the baseline.
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: 'Get the primary resume for a candidate.' It uses a specific verb ('Get') and identifies the exact resource ('primary resume'), distinguishing it from sibling tools like list_candidate_files or get_candidate.
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 fetch the primary resume) and even explains the optional include parameter for getting parsed text content. However, it does not explicitly name alternative tools or when not to use it, so it misses the 'when-not/alternatives' component.
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:

[![mcp-server MCP server](https://glama.ai/mcp/servers/100Hires/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/100Hires/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/100Hires/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/100Hires/mcp-server)

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/100Hires/mcp-server'

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