Recruit CRM MCP Server

Server Quality Checklist

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

Latest release: v0.8.0
Disambiguation4/5
Most tools have clearly distinct purposes and follow a consistent verb_noun pattern, making selection straightforward. However, a few sets (e.g., list_candidate_hiring_stages, list_job_statuses, list_contact_stages, list_pitch_stages) are functionally similar (resolving IDs/labels for different pipelines) and could be confused by an agent, and get_pitch_history versus get_pitched_records have overlapping-sounding names.
Naming Consistency5/5
All tool names use lowercase snake_case and follow a consistent verb_noun pattern (search_candidates, create_job, update_meeting, get_company_details). Even longer names like get_candidate_job_assignment_hiring_stage_history maintain the convention. There are no camelCase or mixed style deviations.
Tool Count2/5
With 69 tools, this server is well above the 25+ threshold that feels heavy. While the breadth might be justified for a full Recruit CRM integration, the count is excessive for a typical MCP server and carries significant selection overhead. The presence of many small lookup/list tools (list_currencies, list_qualifications, list_xml_jobboards, etc.) inflates the count beyond what is likely needed.
Completeness2/5
The server lacks any delete operations for any entity, which is a major gap in CRUD/lifecycle coverage. Additionally, some core entities (tasks, meetings, notes, call logs) have search tools but no corresponding list or get-details tools, and hotlists have no update or remove-record functionality. This leaves agents unable to fully manage the full lifecycle of many objects.
Average 4.4/5 across 69 of 69 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a light note about return contents ('compact entries with job, company, stage, remark, and update metadata'), which is mildly useful context, but it does not mention pagination, ordering, error cases, or scope limitations, keeping transparency at a baseline.
Agents need to know what a tool does to the world before 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: the first front-loads the core purpose, the second briefly describes return contents. No wasted words, no redundancies with schema, and appropriately sized for a simple one-parameter read-only tool.
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 parameter, read-only, with an output schema), the description provides a sufficient overview. However, there is slight ambiguity about whether 'job assignment hiring stage history' covers all job assignments for the candidate or a specific one, and whether any implicit filtering or ordering applies. The output schema likely resolves return format, but the description leaves this scope question open.
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 only parameter (candidate_slug) with a name and description, achieving 100% coverage. The tool description merely repeats 'by candidate slug' without adding semantics like format, constraints, or relationship to other fields. Baseline of 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('one candidate's job assignment hiring stage history'), and the key identifier ('candidate slug'). It distinguishes from siblings like list_candidate_hiring_stages (which implies current stage list) and update_candidate_hiring_stage (which implies mutation), making the tool's purpose 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieval of historical hiring stage data ('history'), but it does not explicitly contrast with alternatives such as list_candidate_hiring_stages for current stages or update_candidate_hiring_stage for changes. There are no exclusions or when-to-use/when-not-to-use statements.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the response includes dropdown or multiselect option values, which provides some behavioral context, but it does not discuss permissions, errors, or other edge cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, target, and key detail about return content without any 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 getter with two fully described parameters, read-only annotations, and an output schema present, the description is sufficient. It captures the purpose and key return content; missing explicit usage alternatives is a minor gap 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 coverage is 100%, so both field_id and entity_type are already fully described. The description restates these parameters as lookup keys and adds the qualifier 'curated' but does not introduce 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 specific verb ('Fetch') and identifies the resource ('custom field details') with clear scope ('one custom field by field_id and entity_type'). It distinguishes itself from list_custom_fields by emphasizing a single field and including option values.
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 by the description ('one custom field') and the existence of sibling list_custom_fields, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. No misleading guidance is present.
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?
Annotations already declare destructiveHint=true, so the description only needs to add nuance. It explains that mark_contact_off_limit and mark_candidate_off_limit control whether related records are also marked off-limit, and it discloses the return fields. This adds meaningful behavioral context beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions 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: the first states the core purpose, the second lists requirements, and the third explains side effects and returns. Every sentence earns its place with no filler or redundancy. It is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, destructive action, output schema present), the description covers purpose, required parameters, side effects, and return values. The only notable omission is reference to alternative tools or reversibility, but this is partially addressed by the sibling list and annotations. Overall, it 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 has 100% coverage with descriptions for all six parameters. The description restates some constraints (e.g., end_date format, max 25 slugs) and explains the boolean semantics, but adds no new information beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Marks up to 25 Recruit CRM companies as off-limit.' It uses a specific verb (marks), identifies the resource (companies), and includes a scope (up to 25). This distinguishes it from sibling tools that target candidates or contacts.
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 gives no guidance on when to use this tool versus alternatives such as mark_candidate_off_limit or mark_records_available. It only states what it does and lists required parameters. There are no exclusions, prerequisites, or alternative tool references, leaving the agent to infer usage from the name.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description adds useful context: the batch limit (up to 25), required parameters, and the return payload (updated slug list, status_id, end_date, reason, API remark). This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before 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 action, and no filler. Every clause adds value: scope, limits, required parameters, format, optional field, and return values.
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 presence of an output schema and annotations covering destructiveness, the description provides enough context for a batch mutation tool: max items, required fields, and return format. It lacks a note on irreversibility or prerequisites like resolving status_id with list_off_limit_statuses, but that's already in 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?
Schema description coverage is 100%, with each parameter already documented. The description restates required parameters and the date format but adds little beyond the schema; the only extra is clarifying that reason is optional, which is already implied by not being in the required list.
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 ('Marks') with a clear resource ('Recruit CRM contacts') and action ('off-limit'), and specifies a batch limit of 25. This clearly distinguishes it from sibling tools like mark_candidate_off_limit and mark_company_off_limit by explicitly targeting contacts.
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 required and optional parameters and the date format, which gives usage constraints. However, it does not explicitly mention alternatives like mark_records_available or explain when to use this tool instead of other off-limit marking tools, leaving differentiation to the resource type alone.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds valuable context: compact summary output, lack of owner filtering, and the URL construction pattern for related entities. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before 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 main function, then limitations and output hint. Every sentence earns its place; 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?
With 8 parameters, an output schema, and annotations, the description provides adequate context: purpose, large-result-set behavior, lack of owner filtering, and URL usage for related entities. It doesn't explain pagination explicitly, but the 'page' parameter is self-explanatory and the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not directly elaborate on parameter syntax or semantics beyond what the schema provides; it only gives context about related_to/related_to_type being available in output, which is tangential.
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 'Search' and resource 'Recruit CRM call logs', and adds the outcome 'compact summaries designed for large result sets', which clearly distinguishes it from sibling CRUD tools for call logs and other entity searches.
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 large result sets via 'compact summaries' and notes the limitation 'Does not support owner filtering', but it does not explicitly state when to use this tool instead of alternatives or mention any alternative tools. Thus 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's 'Updates' aligns. It adds no additional behavioral context such as side effects, idempotency, or audit history, but given annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions 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 includes only essential usage details. 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?
With a full output schema and annotations, the description covers the essential purpose, required fields, and key dependency (list_pitch_stages). It doesn't describe return values, but the output schema handles that, making it complete for this 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 coverage is 100% and the schema already describes each parameter, including the status_id resolution note. The description only repeats the required/optional list without adding 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 clearly states the action ('Updates the pitch stage') and the specific resource ('candidate/contact pitch record'). It distinguishes this tool from siblings like update_candidate_hiring_stage and pitch_candidate_to_contact by focusing on the pitch stage update.
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 lists the required parameters and instructs to resolve status_id via list_pitch_stages, providing clear how-to guidance. It doesn't explicitly state when not to use it or alternatives, but the context is sufficient for an update 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful return-structure context (rows with specific field names), but does not disclose additional behaviors beyond that. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the purpose and the return structure without unnecessary detail. Every word 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 parameters, read-only annotations, and an output schema available, the description is fully sufficient. It specifies what the tool returns and the fields included, making it complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description carries no parameter burden. The baseline for zero-parameter tools is 4, and the description adequately explains what the tool returns.
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 ('Lists') and identifies the exact resource ('Recruit CRM XML job boards for jobs'). It also differentiates from sibling tools by focusing specifically on XML job boards and clarifies the return payload (default_xml_feeds and custom_xml_feeds with id and label).
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 tool when needing the list of XML job boards/feeds. However, it does not explicitly state when not to use it or mention any alternative tools, even though no siblings directly overlap with this functionality.
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?
Annotations already indicate destructive behavior, so the bar is lower. The description adds valuable context by specifying the 25-candidate limit, required fields, and the return payload (updated slug list, status_id, end_date, reason, API remark). This goes beyond the annotations and clearly sets expectations for the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence front-loads the core purpose, and the second efficiently covers requirements and return values. There is no redundant or extraneous wording, and every sentence contributes useful 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 destructive annotation, an output schema, and a relatively simple set of parameters, the description provides sufficient coverage: batch size, required fields, date format, optional parameter, and return payload. It does not mention side effects or how to obtain status_id, but those are handled by the annotations and schema. Minor gaps remain, but the description is strong overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has 100% coverage of parameters, the description does not need to add much. It reiterates the required fields and date format but does not add semantic details beyond the schema, such as how to resolve status_id or what the 'reason' field is for. A 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 action ('Marks'), the resource type ('Recruit CRM candidates'), and the specific operation ('as off-limit'), which differentiates it from similar tools like mark_contact_off_limit and mark_company_off_limit. It also adds the batch limit of 25, which is a useful detail.
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 specifying the target entity as candidates, making it obvious when to use this tool over sibling tools for contacts or companies. However, it does not explicitly mention alternatives or when not to use it, such as when a candidate should be made available again (mark_records_available).
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it requires exact slugs, produces only summaries and follow-ups (not full data), and includes configurable lookback and limits. This helps the agent set expectations.
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 dense but well-structured: opening purpose, then output components, then input constraints, then return scope. It is longer than the calibration examples but every sentence adds value; the list of outputs is long but necessary given the tool's breadth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, many output sections), the description, full param schema, and output schema together provide complete guidance. It covers what the tool does, when to use it, input requirements, output scope, and doesn't need to explain return values since an 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?
Schema description coverage is 100%, with each parameter having a clear description and default. The tool description reinforces the slug input constraint but does not add new per-parameter semantics 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 uses a specific verb ('Prepares a client/account briefing') and clearly identifies the resource (Recruit CRM client/company data) and the use context (before client calls, meetings, etc.). It lists concrete outputs and distinguishes itself from sibling CRUD/search tools, which are all narrower 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?
Explicitly states when to use the tool (before client calls, meetings, check-ins, etc.) and gives input guidance (exact contact_slug or company_slug, not display names). Does not explicitly mention alternatives or when-not-to-use, but the context is clear enough for an agent.
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?
Annotations already mark the tool as read-only and non-destructive, lowering the burden. The description adds valuable context: it returns compact summaries optimized for large result sets and includes company slugs and contact_slugs for building Recruit CRM links. This exceeds what annotations provide.
Agents need to know what a tool does to the world before 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 focused sentences with no redundancy. The first sentence states the main purpose, the second gives a key filtering tip, and the third explains the output slug values for links. 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 tool with 16 parameters, the schema covers all parameters and an output schema exists. The description explains the core use case, filtering via owner_id, and the link structure. It does not discuss pagination, but page and limit are clearly defined in the schema, and the output schema covers return 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?
All 16 parameters are fully documented in the schema (100% coverage), so the baseline is 3. The description reinforces the owner_id usage by referencing list_users, but this information is already in the schema's owner_id description. No additional parameter syntax or format details are provided 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 it searches Recruit CRM companies and returns compact summaries designed for large result sets, distinguishing it from list_companies and get_company_details. The verb 'search' plus the resource 'companies' 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 explicit guidance on using owner_id to scope results to a specific user and directs the agent to list_users for resolving user IDs. It also frames the tool as suitable for large result sets, but it does not explicitly contrast with sibling tools like list_companies or other search tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: returns compact summaries designed for large result sets, includes specific slug and hiring_pipeline_id fields, and explains how slugs map to app URLs. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions 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, each with a distinct purpose: the first states the tool's function, the second gives filtering and chaining guidance, and the third explains return fields and URL usage. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 35-parameter search tool with full schema coverage, annotations, and an output schema, the description is reasonably complete. It covers the tool's search intent, key related tools (list_users, list_candidate_hiring_stages), and return values. It could explicitly contrast with list_jobs for full completeness, but the overall guidance is solid.
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 35 parameters are already documented. The description repeats the owner_id filter guidance but does not add new meaning to individual parameters; its value lies in the return fields and usage chaining rather than parameter 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?
The description clearly states 'Search Recruit CRM jobs and return compact summaries designed for large result sets,' specifying the verb (search), resource (jobs), and a distinct purpose (compact summaries for large result sets) that differentiates it from list_jobs or get_job_details. It also lists the return fields and URL usage, further clarifying 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 gives explicit usage context: filter by owner_id after resolving user IDs with list_users, and use hiring_pipeline_id with list_candidate_hiring_stages for stage lookup. It does not explicitly mention when not to use this tool versus alternatives like list_jobs, so a 5 is not warranted.
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?
Annotations already declare readOnlyHint and destructiveHint, and the description adds valuable behavior: returns compact summaries for large result sets, lacks owner filtering, and returns related_to fields that can construct app URLs. This goes beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and scope. Each sentence provides distinct value—search behavior, limitation, and output usage—without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters and an output schema, the description covers key contextual aspects: purpose, compact output, a limitation, and a use case for the related fields. It does not discuss filtering details, but those are implied by the schema.
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 baseline is 3. The description adds meaning by explaining that related_to and related_to_type values can be used to build Recruit CRM app URLs, providing extra context beyond the schema's basic 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 clearly states the tool searches Recruit CRM notes, which distinguishes it from siblings like search_candidates or search_tasks. It also mentions compact summaries and no owner filtering, further specifying 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 indicates it is meant for searching notes, especially large result sets, and explicitly notes it does not support owner filtering. However, it does not name alternative tools or provide explicit when/when-not guidance compared to sibling search 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?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating and potentially destructive operation. The description adds return behavior ('Returns a compact summary with the company slug') and prerequisites. However, it does not clarify whether omitted fields are preserved or reset during an update, which is important for a mutation tool. With annotations covering safety signals, the additional value is modest, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions 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 long, with the main purpose front-loaded in the first sentence. Each sentence contributes necessary information: what it does, what is required, how to resolve IDs, and what is returned. 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?
Given the tool's complexity (19 parameters, mutation, annotations, output schema), the description is mostly complete. It covers the core operation, required fields, resolution steps, and return type. The only notable gap is the lack of clarity on partial update semantics (whether unspecified fields are left unchanged), but the rich schema and annotations reduce the burden on the description.
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 the schema already documents all parameters. The description adds value by explaining the role of company_slug as the identifier, identifying updated_by as the user performing the update, and explicitly instructing to resolve user IDs and custom field IDs via other tools. This goes beyond what the schema notes, enriching the semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Updates one existing Recruit CRM company by company_slug.' The verb 'updates' is specific, the resource 'Recruit CRM company' is identified, and the unique identifier 'company_slug' is specified. This distinguishes it from siblings like create_company, list_companies, search_companies, and get_company_details.
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 it updates one existing company and lists required parameters: 'Requires company_slug and updated_by.' It also gives practical guidance for parameter preparation: 'Resolve user IDs with list_users and custom field IDs with list_custom_fields for entity_type=companies.' However, it does not explicitly name alternative tools or mention when-not-to-use, so a 4 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?
The annotations already mark the tool as destructive (destructiveHint=true), so the description does not need to restate that. It adds a useful note about the return value ('compact summary with the contact slug') and the 'at least one field' requirement, but does not elaborate on side effects, overwrite semantics, or error cases, which is acceptable given the 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?
Three focused sentences: the first states the core action, the second gives the required-parameter rule and resolution sources, and the third describes the return value. Every sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, an output schema, and annotations, the description covers the essential usage constraints and foreign-key resolution strategies. It does not enumerate all possible fields, but the schema already does that. The only minor gap is not mentioning what happens if no update field is provided beyond the requirement itself, but that is adequately communicated.
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 covers all 22 parameters (100% coverage), so the baseline is 3. The description adds meaningful semantics by clarifying that at least one update field is required and by explaining how to resolve foreign keys (user IDs via list_users, company slugs via search_companies/list_companies, stage IDs via list_contact_stages, custom field IDs via list_custom_fields). This goes beyond the schema's per-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 specific verb ('Updates') and precisely identifies the resource ('one existing Recruit CRM contact') and the addressing mechanism ('by contact_slug'). This clearly distinguishes it from sibling tools like create_contact, list_contacts, search_contacts, and get_contact_details.
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 states the required inputs ('Requires contact_slug and at least one field to update') and provides explicit pointers to related tools for resolving user IDs, company slugs, stage IDs, and custom field IDs. It does not explicitly state when not to use this tool, but the 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds that it updates an existing job and requires at least one field to update, which implies partial update behavior. It also notes the return summary. However, it does not disclose potential side effects or permission requirements beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it leads with the primary purpose, states requirements, then provides a compact list of lookup tool mappings, and ends with the return type. Every sentence adds value, and the length is appropriate for a tool with 43 parameters.
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 (43 params, nested objects) and that an output schema exists, the description effectively covers how to source parameters and what to expect. It lacks explicit mention of corner cases or whether updates are partial vs. full, but it covers the main usage requirements. The list of sibling tools also helps contextualize that this is the job update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description goes beyond the schema by mapping each complex parameter to the correct list/search tool (e.g., 'list_job_statuses for job status IDs'), helping the agent know how to obtain valid values. It also clarifies the requirement of 'at least one field to update,' which is not explicit 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 'Updates one existing Recruit CRM job by job_slug,' which is a specific verb+resource combination. It distinguishes itself from create_job by saying 'updates one existing' and from other update tools by naming the specific entity and key identifier.
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 guidance: requires job_slug, updated_by, and at least one field to update. It also lists the exact lookup tools needed for each parameter group (list_users, search_companies, list_job_statuses, etc.). It stops short of explicitly stating when not to use it (e.g., for creation) or comparing against alternatives, but the context 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?
Annotations already declare destructiveHint=true, signaling a mutation. The description adds valuable behavioral details: duplicate input slugs are ignored, and partial success returns added_slugs with an errors array. It does not cover auth or rate limits, but with annotations present, this is adequate and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions 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 essential constraints and return behavior. Every sentence earns its place, making it concise and well-structured.
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?
The tool is simple with 2 parameters and an output schema present. The description covers the operation, constraints, and return details. With an output schema explaining return structure, the description is complete for the given 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 clear descriptions for hotlist_id and related_slugs. The description does not add parameter-specific semantics beyond 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 action ('Adds'), the resource ('Recruit CRM record slugs'), and the target ('an existing hotlist'). It differentiates from sibling tools like create_hotlist by specifying modification of an existing hotlist and includes specific constraints like max 10 and duplicate handling.
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 sets the context: adding records to an existing hotlist. It implies that create_hotlist is for creating new hotlists, but it does not explicitly name alternatives or offer when-not-to-use guidance. This is clear context without exclusions, which fits a score of 4.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context beyond annotations: the subtree narrowing behavior (passing parent or child field_id) and the critical constraint that parent field_id and value must be included when setting a child custom field. This is useful for the agent to understand the tool's role in a broader workflow. However, it doesn't detail error conditions or the exact return shape, though the output schema likely covers the latter.
Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose and followed by the optional parameter behavior and an important constraint. No filler or redundancy; 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?
For a read-only tool with good annotations, an output schema, and two well-described parameters, the description is complete. It covers the essential dependency workflow (including the parent/child constraint) that an agent needs to know. There is no notable gap 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 schema already documents both parameters well: entity_type is an enum, and field_id explains the subtree narrowing. The description repeats this information and adds the dependency-setting context, which is more about usage than parameter syntax. Baseline 3 is appropriate since the description does not significantly add 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 clearly states the tool fetches parent-child dependency relationships for custom fields, with a specific verb and resource. It distinguishes itself from sibling tools like list_custom_fields and get_custom_field_details by focusing on dependencies, not just listing fields or details. The optional field_id subtree narrowing further clarifies 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 understand or set dependencies, especially noting that when setting a child field, the parent field_id and value must be included. It does not explicitly exclude alternatives or name alternative tools, but the context is clear enough for an agent to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context beyond this: pagination is MCP-side because the upstream endpoint returns all rows, and returns compact id/question rows. This explains behavioral traits not covered by 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 long, front-loaded with the core action and resource, and every clause adds meaningful information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two well-documented parameters, an output schema, and strong annotations, the description is complete. It explains what, why, and the pagination behavior without over-explaining.
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 'page' and 'limit' fully described. The description reinforces the pagination mechanism but does not add significant new parameter details, 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 'Lists Recruit CRM candidate questions' with the specific purpose of 'resolving candidate question IDs.' It also distinguishes itself by noting MCP-side pagination and the compact return format, which separates it from any potential sibling 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 implies usage when resolving candidate question IDs, and it clarifies why pagination is handled MCP-side. While it does not explicitly name alternatives or exclusions, there are no direct sibling tools for candidate questions, so 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering safety. The description adds that results are sorted most-recently updated first, returns compact summaries with slugs, and that filtered queries should use a different tool, offering useful behavioral context beyond 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 three succinct sentences that front-load the main action, state ordering, describe the return format, and point to an alternative. No filler or redundant 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 rich schema and annotations, the description provides sufficient context for an agent to select the tool: it is a read-only list of all candidates, sorted, returning compact summaries, with an explicit redirect to search_candidates for filtered queries. The output schema handles return structure, and parameter descriptions handle limits and sort options.
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 5 parameters have full descriptions in the schema (100% coverage), so the schema carries the documentation burden. The main description does not add parameter-level meaning beyond the schema, though the include_contact_info parameter already includes guidance on PII and response size within the schema itself.
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 'Lists' and clearly identifies the resource 'all candidates in the account'. It distinguishes itself from the sibling search_candidates by noting it is unfiltered, and adds value by stating the default sort order and compact summary format.
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 directs users to search_candidates for filtered queries, providing a clear alternative. However, it does not explicitly name get_candidate_details for full detail retrieval, though the mention of 'slug values for candidate detail lookup' implies that workflow.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the key behavioral detail of 'MCP-side pagination', explaining that pagination is handled by the server rather than the API. This goes beyond annotations and provides useful context for the caller.
Agents need to know what a tool does to the world before 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 first sentence states the action and resource, the second lists return fields and use case. Every word earns its place; it is well-structured and front-loaded.
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, strong annotations (read-only), 100% schema coverage, and presence of an output schema, the description is complete. It covers what the tool does, what it returns, and the pagination behavior, leaving no critical gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with page and limit already described in detail. The description's 'MCP-side pagination' phrase adds minimal value because the schema's page parameter already states pagination is applied by the MCP server. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lists' and identifies the resource 'Recruit CRM currencies'. It clearly distinguishes this tool from sibling list tools (e.g., list_call_types, list_languages_and_proficiencies) by stating the exact rows returned and their purpose for candidate and job currency_id fields.
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: this tool returns currency rows needed for candidate and job currency_id fields. It implies when to use it (when currency options are needed) though it doesn't explicitly state exclusions or alternatives. Since there is no direct sibling currency tool, this is sufficient.
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?
Beyond the readOnlyHint=true annotation, the description discloses that pagination is 'MCP-side' and that the tool returns standard proficiency IDs. This adds behavioral context about how the tool operates (server-side pagination) and what it returns, which is not captured by the 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 long and front-loaded with the core action. The first sentence states what it does, and the second provides a direct usage hint. Every word contributes value; there is no fluff or repetition.
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 read-only list tool with two optional params, an output schema, and clear annotations, the description is complete. It explains the purpose, the pagination behavior, and the intended downstream use (language_skills). The output schema covers return structure, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (page and limit) with detailed descriptions, including the rationale for server-side pagination. The tool description adds no further parameter-level meaning, 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 the specific verb 'Lists' with the resource 'Recruit CRM languages' and clarifies that it also returns 'standard proficiency IDs'. This clearly distinguishes it from sibling list tools (e.g., list_currencies, list_qualifications) by focusing on language-related 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 provides an explicit usage context: 'Use language_id and proficiency_id for candidate language_skills.' This tells the agent when to use the tool. However, it does not mention alternatives or when not to use it, and there are no directly competing sibling tools, so it doesn't need 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?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds context about returning 'status_id and label values' but does not disclose additional behavioral traits such as result ordering, pagination, or errors. This is a moderate addition beyond annotations, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions 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 is front-loaded with the object and action. It includes necessary context without verbosity, earning a perfect score for conciseness.
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 (no parameters), the presence of an output schema, and the annotations, the description fully suffices. It states what the tool does, what it returns, and for what purpose, making it complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description implies no inputs are needed by simply stating it lists stages. There are no parameter details required, and the schema is fully covered with no properties.
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 Recruit CRM pitch pipeline stages', which is a specific verb and resource. It further distinguishes itself from sibling list tools by specifying 'pitch pipeline' and mentions returning 'status_id and label values', making its 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 specifies the primary use case: 'for resolving stage names used by update_candidate_pitch_stage'. This gives clear context on when to use the tool. However, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description builds on that by adding return format details (compact summaries with specific fields), optional include_teams and include_contact_info behaviors, and the critical fact that it returns all users in a single response with no pagination. This goes beyond the annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions 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, each earning its place: the first states the purpose and output, the second explains why the tool's IDs are important across the platform, and the third covers optional parameters and pagination. No filler 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?
Even though an output schema exists (not shown), the description sufficiently explains return values including field names and optional inclusions. It also covers pagination behavior (none) and connect to other entities in the system. For a read-only list tool with two optional params, this is complete 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?
Both parameters (include_teams, include_contact_info) are fully described in the schema with 100% coverage, and the description essentially repeats the same information. The baseline of 3 is appropriate since the schema does the heavy lifting; the description adds minimal extra meaning beyond what is already 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 the tool 'Lists all Recruit CRM users' with a specific verb and resource, and describes the output as 'compact summaries' with specific fields. It distinguishes itself from sibling list tools like list_teams and list_candidates by focusing on users and their IDs.
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 explains that user IDs from this tool are used as owner_id, created_by, updated_by, etc. across many entities, giving strong context for when to use this tool. It does not explicitly exclude any alternative but implicitly positions this as the source for user references and mentions optional flags to tailor output.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description enriches this by explaining the exact mutation scope: updating the candidate and optionally creating up to 10 work history and 10 education history rows. It discloses partial-success behavior ('partial-success details for history operations'), resume file format constraints, and that file-type custom fields accept only a direct download URL. No contradiction with annotations exists.
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 four sentences, front-loaded with the primary purpose. Each subsequent sentence earns its place: requirements, resolver guidance, file format constraints, and return summary. It is concise relative to the 44-parameter schema, though it is dense and could be slightly restructured for readability. No filler or repetition of schema-only 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 tool with 44 parameters, nested arrays, and no output schema content in the description, the description covers the essential context: target resource, required/conditional fields, how to resolve IDs, file format restrictions, and return behavior. It does not explicitly state whether unspecified fields are left unchanged or reset, but the up to 10 rows and partial-success details suggest a reasonable update semantics. Given the output schema exists and annotations are present, the description is complete enough for an agent to 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?
With 100% schema description coverage, the baseline is 3, but the description adds meaningful semantics beyond the schema. It maps logical parameters to resolver tools ('currency_id with list_currencies', 'language_skills with list_languages_and_proficiencies'), clarifies the resume field accepts base64 or URL, and explains that file-type custom fields only accept a direct download URL. It also introduces the conditional requirement that at least one of first_name or last_name must be provided, which is not encoded in the schema's required list.
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 ('Updates'), resource ('one existing Recruit CRM candidate'), and identifier ('by candidate_slug'), distinguishing it from sibling tools like create_candidate and search_candidates. It also names the exact operation scope (update plus optional history creation), leaving no ambiguity about 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 description gives explicit guidance on resolving foreign keys ('Resolve user IDs with list_users, currency_id with list_currencies...'), which helps agents prepare correct parameter values. It also clearly implies the tool is for updating an existing candidate (not creating one), but it does not explicitly name alternative tools or state when not to use it. The conditional requirement 'at least one of first_name or last_name' adds useful usage 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?
Annotations already mark destructiveHint=true, and the description adds useful context beyond that: it clarifies the default behavior (only changes hiring stage) and the side effect of create_placement=true creating a placement record. No contradiction with annotations. It could disclose more about the destructive nature (e.g., overwriting existing stage), but it's reasonably 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 four sentences, front-loaded with purpose and key required parameters, followed by important behavioral nuances. No fluff or redundancy; 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?
Given the rich schema (100% param descriptions), annotations (destructiveHint), and output schema, the description covers all essential aspects: purpose, required fields, side effects (placement creation), status_id resolution, and remark formatting. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces the meaning of status_id resolution and create_placement, but does not add significant new information 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 tool's function with a specific verb and resource: 'Updates one candidate's hiring stage for a specific Recruit CRM job.' It also distinguishes from sibling tools like update_candidate_pitch_stage by mentioning hiring stage and placement 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?
Provides clear context on when to use: it's for updating a hiring stage, and instructs to resolve status_id via list_candidate_hiring_stages. It explains the create_placement flag behavior. However, it does not explicitly name alternative tools or state when not to use this 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 annotations already marking this as destructive (destructiveHint: true), the description adds valuable behavioral details: duplicate checking via allow_duplicate, the requirement for owner_id and created_by, and the compact summary output with company slug. These details go beyond the raw annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: what the tool does, required inputs, and how to resolve dependencies. The duplicate-check behavior and return format are also covered. No redundant or filler 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?
Given the high parameter count (19) and full schema coverage, the description focuses on the non-obvious aspects: duplicate policy, ID resolution, and output. An output schema exists, so return details need no expansion. It could mention validation failures, but this is a minor omission.
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 all 19 parameters are already described in the input schema. The description adds semantic value by clarifying the purpose of allow_duplicate ('Checks duplicates by company_name unless allow_duplicate=true') and advising to resolve IDs via list_users and list_custom_fields, which helps interpret owner_id, created_by, and custom_fields.
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 'Creates one Recruit CRM company', using a specific verb and resource that clearly distinguishes it from sibling tools like search_companies, update_company, and list_companies. The scope ('one') and the duplicate-check behavior further clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states required parameters and provides actionable guidance: 'Resolve user IDs with list_users and custom field IDs with list_custom_fields for entity_type=companies.' This gives clear context for when to use the tool by outlining prerequisites. However, it does not explicitly contrast with alternatives like update_company, so it stops short of full differentiation.
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?
Annotations already indicate a non-read-only, destructive-capable operation. The description adds valuable context: calendar invites are not sent by default, and the flag to change that behavior. It also notes the return value (compact meeting summary). This goes beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: creation statement, required fields, and crucial ID resolution/calendar behavior. No fluff, clear structure.
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 24-param schema and 6 required params, the description focuses on the essentials: required fields, ID resolution, and the calendar invite default. It doesn't mention optional params, but the schema covers them. The note about the return summary is a nice touch. Slightly more could be said about the meaning of openWorldHint or related_to constraints, but it's sufficient.
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 baseline is 3. The description adds extra guidance on resolving IDs for meeting_type_id and owner_id, and clarifies the default behavior of do_not_send_calendar_invites. This pushes it above baseline without needing to enumerate all 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 opens with 'Creates one Recruit CRM meeting' – a specific verb and resource. It clearly distinguishes from sibling tools like search_meetings and update_meeting by focusing on creation. No 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?
Explicitly lists required parameters and directs the agent to resolve IDs via list_meeting_types and list_users. It also explains when to set do_not_send_calendar_invites to false. However, it doesn't explicitly mention update_meeting as the alternative for modifying existing meetings, so it stops short of full when-not 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?
Annotations already establish the operation as non-read-only and destructive, so the description does not need to restate that. It adds value by noting that the description supports basic HTML/rich text and that the tool returns a compact note summary. These are behavioral details beyond the annotations, though the return summary may be redundant given the output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions 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 long, with no wasted words. It front-loads the primary action and resource, then provides essential prerequisites and return behavior. Every sentence contributes unique information, making this an excellent example of 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?
For a create tool with 14 parameters and an output schema, the description covers the core essentials: required fields, ID resolution, content format, and return summary. It doesn't explain the optional association parameters, but the schema handles those. Given the complexity, a small gap exists around behavior for edge cases (e.g., invalid related_to), so 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds meaningful guidance by telling the agent to resolve IDs via list_note_types and list_users, which is not in the schema for those parameters. This extra context helps the agent select valid values, elevating the score to 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 'Creates one Recruit CRM note' with a specific verb and resource. It distinguishes itself from sibling tools like update_note and search_notes by focusing on creation. The mention of required fields further anchors 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 explicitly directs users to resolve note type IDs with list_note_types and user IDs with list_users, providing clear guidance for prerequisite lookups. It does not explicitly say when NOT to use this tool, but the context is clear. This earns a 4 rather than 5 because no exclusions or alternative tool mentions are given.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate these. It adds useful behavioral context by noting that the description parameter supports basic HTML/rich text and that the tool returns a compact task summary. No contradictions with the 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 four short sentences, front-loaded with the core purpose, followed by required fields, prerequisite resolution, and return format. Every sentence serves a purpose with no repetitive or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter tool with full schema descriptions and an output schema, the description covers the essential operational details: required fields, ID resolution, HTML support, and return summary. It doesn't need to explain every parameter because the schema already does that.
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 baseline is 3. The description adds value beyond the schema by specifying which tools to use to resolve task_type_id and user IDs, and by explicitly stating HTML support for the description parameter. This helps the agent understand how to populate parameters correctly.
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 ('Creates') and resource ('one Recruit CRM task'), distinguishing it from sibling tools like search_tasks and update_task. The singular 'one' clarifies the scope, and the key required fields are listed.
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 operational context: it lists the required fields and tells the agent to resolve task_type_id via list_task_types and user IDs via list_users. It does not explicitly mention alternatives like update_task for modifications, but the guidance is actionable and not misleading.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral details: it openly mentions 'compact assignment summaries' and that it returns candidate_slug values for Recruit CRM links. It does not contradict annotations, and the additional context is helpful, though it omits pagination behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds value: main function, filtering/resolution guidance, and return value format. There is no redundancy or fluff, exemplifying appropriate 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 presence of an output schema and annotations, the description covers the essential aspects: purpose, filtering, ID resolution, and return value hints. It lacks explicit pagination or limit behavior details, but those are already in the schema, so the description is sufficiently complete for this tool's complexity.
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%, providing a baseline of 3. The description goes beyond the schema by explaining status_id resolution, including using the job's hiring_pipeline_id and the fallback to 0 for global stages, which is valuable for correct invocation. This additional guidance justifies a 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 'Fetches assigned candidates for one Recruit CRM job and returns compact assignment summaries,' using a specific verb, resource, and scope. This distinguishes it from sibling tools like list_candidates (all candidates) or get_candidate_details (single candidate), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool, such as narrowing to a hiring stage and resolving stage IDs with list_candidate_hiring_stages. However, it does not explicitly state when not to use it vs alternatives, so it misses the 'when-not' guidance needed for 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?
The description adds useful behavioral details beyond the readOnlyHint and destructiveHint annotations: it returns compact summaries with slug values for subsequent detail lookup, and notes the default sort behavior. This gives agents a clear expectation of output shape and intended follow-up actions.
Agents need to know what a tool does to the world before 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 high information density. The first sentence states the core purpose and default ordering; the second clarifies the response format and points to the alternative tool for filtered queries. 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?
Given the output schema and annotations, the description is adequately complete. It covers the tool's scope, response format, and when to use an alternative. It does not explicitly mention pagination, but that is already captured in the parameter schema. Slightly more detail on the include_contact_info trade-off could enhance completeness, but it is present in 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?
Schema description coverage is 100%, and each parameter is already well-documented. The description adds context about compact summaries and default sorting that indirectly informs parameter usage, but does not elaborate on each parameter. Baseline of 3 is appropriate given the 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 lists all contacts in the account and specifies the default sort order (most-recently updated first). It explicitly differentiates itself from search_contacts by directing filtered queries there.
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?
Provides explicit guidance: use this tool for unfiltered lists, and use search_contacts when filtering is needed. This clear alternative reference helps agents choose correctly.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it returns 'curated' metadata, defaults to searchable fields, and notes the include_non_searchable option. This goes beyond the annotations and helps the agent understand the response set.
Agents need to know what a tool does to the world before calling it. Descriptions 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, two sentences long, and front-loaded with the core purpose. It avoids redundant information and uses the second sentence for a key parameter behavior, earning 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 output schema, annotations, and parameter coverage, the description is nearly complete. It covers what the tool lists, for which entity types, and the default vs optional behavior. It could mention pagination or relationship to get_custom_field_details, but those are not critical for this simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explicitly stating the default behavior ('Returns searchable fields by default') and the effect of setting include_non_searchable=true. This supplements the schema descriptions, making parameter semantics clearer.
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 resource 'custom field metadata' with a specific scope of entity types (candidates, contacts, companies, jobs, deals). It distinguishes itself from sibling tools like get_custom_field_details by focusing on listing curated metadata rather than fetching a single field's details.
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 what the tool does (lists custom field metadata for a specific entity type) and explains the default behavior (searchable fields only) with an option to include non-searchable. It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for an AI agent to choose this tool over a details or dependencies endpoint.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. The description adds valuable context by disclosing the duplicate-prevention check ('Checks existing candidate/contact pitch records unless allow_duplicate=true') and the fact that no email is sent, preventing a false expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, requirements+duplicate behavior, and the email caveat. 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?
The description covers the core behavior, requirements, duplicate handling, and a critical limitation (no email). With an output schema present, return values are covered elsewhere. A minor gap is that it doesn't state the exact outcome if duplicate checks fail, but this is acceptable for a well-scoped action.
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 meaning by tying allow_duplicate to its behavior: it bypasses the duplicate check. It also confirms the required parameters in the first sentence, reinforcing 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 opens with a specific verb+resource: 'Marks one Recruit CRM candidate as pitched to one contact.' This clearly distinguishes from sibling tools like get_pitch_history (read) or update_candidate_pitch_stage (stage change).
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 implies when to use via the action itself and adds an explicit exclusion: 'the API does not send an email.' However, it doesn't mention alternative tools for related operations like viewing pitch history or updating pitch stage.
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?
Annotations already declare readOnlyHint and non-destructive behavior, so the bar is lower. The description adds valuable context: results are compact summaries optimized for large result sets and returns slug values for downstream use. No contradictions with 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 core purpose, and each phrase earns its place: purpose, large-result-set behavior, owner_id scoping, and slug return. 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?
Given 23 parameters and an output schema, the description covers the essential mental model: search with owner scoping, get compact summaries, use slugs for details. It does not describe custom_fields or other filter types in prose, but the schema fully covers those, so the description is complete enough.
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 covers all 23 parameters at 100%, so baseline is 3. The description supplements key workflow details: owner_id requires resolving via list_users, and the output is slugs usable with get_candidate_details or app links. This is useful beyond the schema alone.
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 'Search Recruit CRM candidates and return compact summaries designed for large result sets,' which clearly states the verb, resource, and output style. It distinguishes itself from list_candidates (compact vs. likely full records) and other search_* siblings by the candidate resource.
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 concrete guidance: filtering by owner_id and resolving user IDs via list_users, and it suggests get_candidate_details as a follow-up using returned slugs. However, it does not explicitly say when not to use this tool or name direct alternatives like list_candidates for full candidate lists.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: it returns compact summaries for large result sets and clarifies which parameters do not count as independent real filters. This is valuable contextual information, though it does not detail pagination or exact return format, which the output schema likely covers.
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded with the main purpose, and every sentence contributes meaningful information. It avoids redundancy with the schema and annotations, making it compact 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?
Given the tool's complexity (22 parameters), existing output schema, and annotations, the description provides essential usage constraints and behavioral notes (compact summaries, filter requirement). It does not mention how multiple filters combine or the behavior of contact_slug ignoring other filters, but those are documented in the schema. Overall, it is sufficiently complete for an agent to select and invoke the tool 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 description coverage is 100%, so the baseline is 3. The description adds genuine value by explaining owner_id's semantics (scope to a user) and cross-referencing list_users, plus giving a clear rule about which parameters cannot serve as the sole filter. This goes beyond the schema's per-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 uses a specific verb-plus-resource construction ('Search Recruit CRM contacts') and clearly indicates the tool's scope (filters, compact summaries for large result sets). It distinguishes itself from sibling tools like list_contacts and get_contact_details by focusing on filtered search with a compact summary output.
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 (searching with filters) and practical guidance: owner_id scoping, resolving user IDs via list_users, and the requirement for at least one real filter. It does not explicitly state when not to use it or name alternatives like list_contacts for unfiltered listing, so it stops short of full exclusion 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds meaningful behavioral context by noting that results are 'compact summaries designed for large result sets' and that it returns related_to/related_to_type values for building app URLs. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions 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 long, front-loaded with the core purpose, and every sentence contributes useful information. There is no fluff or redundancy, making it an excellent example of concise, well-structured documentation.
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 13 parameters, no required fields, an output schema, and rich annotations, the description covers the essential aspects: purpose, key filtering strategy, and output usage for app URLs. It appropriately leaves parameter details to the schema, and the mention of 'large result sets' plus the 'page' parameter addresses pagination implicitly. A minor gap is the lack of explicit guidance on combining multiple filters, but overall it is 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 the baseline is 3. The description adds value by explaining how to use owner_id ('scope results to a specific user; resolve user IDs with list_users') and clarifies the role of related_to/related_to_type in output URLs. This extra context elevates it above 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 explicitly states the verb 'search' and resource 'Recruit CRM tasks', with the distinctive 'compact summaries designed for large result sets' clarifying its purpose and differentiating it from sibling search tools. This is a specific and unambiguous statement of 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 description provides concrete usage guidance: 'Filter by owner_id to scope results to a specific user; resolve user IDs with list_users.' This gives a clear use case and cross-references another tool, but it does not explicitly contrast with alternatives like search_meetings or search_notes, so it earns a 4 rather than 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?
Annotations already indicate destructiveHint=true, so the mutating nature is disclosed by structured data. The description adds value by stating the output is a 'compact call log summary with duration in seconds' and that at least one field must be updated, which informs expected behavior and potential 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 four sentences, tightly written, with the core purpose in the first sentence and supporting details in the following sentences. No redundant or vague wording 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?
For a tool with 18 parameters and an output schema, the description provides a workable overview: it states the operation, required fields, key validation, and output format. It doesn't enumerate every parameter, but the schema already does that, so this is sufficient.
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 description coverage is 100%, so parameters are already well-documented. The description adds useful cross-references: explaining that call type IDs can be resolved via list_call_types, user IDs via list_users, and that related_to_type must be one of three values. It also clarifies the requirement of at least one update field beyond the two required 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 the specific verb 'Updates' with a clear resource ('one existing Recruit CRM call log') and identifies the key identifier (call_log_id). This clearly distinguishes it from create_call_log (creation) and search_call_logs (read-only search).
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 explicit requirements: call_log_id, updated_by, and at least one field to update. It also directs users to list_call_types and list_users for resolving IDs, and constrains related_to_type to three values. This gives clear context though it doesn't explicitly name alternative tools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, so the update nature is known. The description adds valuable context: it requires at least one field to update (implying partial update), supports HTML/rich text for the description field, and returns a compact summary. These details go beyond the annotations and help the agent understand call semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose. Every sentence adds necessary information: prerequisites, ID resolution, HTML support, and return type. There is 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?
Given the tool has 14 parameters and an output schema, the description covers the essentials: what it does, required parameters, the need for at least one update field, how to resolve dependent IDs, and the return shape. It does not explain every optional parameter, but the schema fully covers those. A small gap is that it doesn't explicitly state whether updates merge or replace, but 'at least one field to update' strongly implies partial update.
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 extra meaning by advising to resolve note_type_id via list_note_types and updated_by via list_users, and by clarifying that description supports basic HTML/rich text, which is not entirely obvious from the schema description alone. This elevates it above 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 it 'Updates one existing Recruit CRM note by note_id,' using a specific verb and resource. It distinguishes from sibling create_note by specifying 'one existing' note, and the scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the required parameters (note_id, updated_by) and the condition 'at least one field to update,' which indicates when the tool is appropriate. It also directs users to list_note_types and list_users for resolving IDs, which is practical usage guidance. However, it does not explicitly mention when not to use it or name alternative tools for creating notes.
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?
Annotations already flag mutation (readOnlyHint=false, destructiveHint=true). The description adds useful context: the need for at least one update field, HTML/rich text support, and the compact summary return. No contradiction with 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?
Three concise, front-loaded sentences with no unnecessary detail. Every clause adds meaningful guidance. Excellent structure.
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 18-parameter surface and rich schema, the description handles the essential high-level usage: requirements, ID resolution, HTML support, and return type. It could additionally clarify whether omitted fields are preserved, but the schema and annotations cover most remaining details.
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 baseline is 3. The description adds value beyond the schema by noting the cross-references for task_type_id and user IDs, and by highlighting the at-least-one-field requirement. This helps the agent understand how to populate parameters correctly.
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 and resource: 'Updates one existing Recruit CRM task by task_id.' This clearly differentiates from sibling tools like create_task and search_tasks. The target 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?
Provides explicit usage requirements (task_id, updated_by, at least one field to update) and points to list_task_types and list_users for resolving IDs. It stops short of explicitly saying when not to use this tool versus alternatives, but the context 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the baseline is lower. The description adds context about the default 'Assigned' stage, unsupported features, and the need to use another tool for non-default stages. This goes beyond the annotations and helps the agent understand the tool's behavior, though it could mention potential side effects like overwriting an existing assignment.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentence states the core purpose, and the second lists limitations and the alternative tool. It is front-loaded, precise, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter tool, existing annotations, and presence of an output schema, the description sufficiently covers purpose, requirements, limitations, and alternatives. It does not need to explain return values because the output schema handles that.
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 each parameter having a description, so the baseline is 3. The description reinforces the required parameters (candidate_slug, job_slug, updated_by) but does not add significant detail beyond the schema. It implies that no stage parameter exists because only the default stage is used, which is useful context but not directly parameter-specific.
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 'Assigns one Recruit CRM candidate to one job at the default Assigned hiring stage,' specifying the verb (assigns), resource (Recruit CRM candidate and job), and scope (default stage). It also distinguishes itself from sibling tools by noting unsupported features and directing to update_candidate_hiring_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (for default-stage assignment) and when not to use it: 'Does not support remarks, explicit stage selection, stage_date, or create_placement' and 'use update_candidate_hiring_stage afterward when a non-default stage or remark is needed.' This provides clear guidance on 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?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so it is known to be a mutating operation. The description adds value by disclosing that it creates a single contact, lists required fields, and notes the return format ('compact summary with the contact slug'). This goes beyond the annotation and helps set agent expectations.
Agents need to know what a tool does to the world before 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 action, then required fields, resolution guidance, and return summary. No filler or repetitive content. 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 22 parameters and an output schema, the description still manages to cover the essential aspects: what the tool does, required params, how to resolve the most easily-confused parameters, and the response format. The output schema covers return values, and the schema covers optional params, so the description is complete for this complexity level.
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% (baseline 3), but the description adds meaningful semantic hints not present in the schema: it maps owner_id to list_users, company_slug to search_companies/list_companies, stage_id to list_contact_stages, and custom_fields to list_custom_fields. These resolution pointers help the agent correctly populate parameters, which is more than the schema's terse property 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 specific verb+resource pair: 'Creates one Recruit CRM contact.' It clearly distinguishes this create operation from sibling tools like create_candidate, create_job, or create_company. The mention of required fields further 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit resolution guidance: 'Resolve user IDs with list_users, company slugs with search_companies or list_companies, stage IDs with list_contact_stages, and custom field IDs with list_custom_fields.' This tells the agent which sibling tools to use for prerequisites. It stops short of stating when not to use this tool (e.g., for updates), but the context 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?
Annotations already indicate non-read-only and destructive behavior, so the description's job is lighter. It adds useful context by explaining the meaning of 'shared' (team-shared vs private) and by recommending a way to resolve user IDs, which goes beyond the schema. It doesn't contradict the 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: first states the action, second lists requirements and a helpful tip. No redundant information, and every sentence contributes to the agent's decision-making and execution.
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 create operation with 4 required parameters and an output schema present, the description fully covers purpose, requirements, parameter semantics, and a key dependency (list_users). It lacks clutter and provides everything an agent needs to successfully 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?
Schema covers all parameters, so baseline is 3. The description adds value by clarifying the 'shared' flag semantics and explicitly identifying 'created_by' as a user ID with a resolution method, improving parameter understanding 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 action with a specific verb and resource: 'Creates one Recruit CRM hotlist.' It distinguishes itself from sibling tools like search_hotlists and add_records_to_hotlist by focusing solely on the creation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by listing required parameters and explicitly mentions resolving user IDs with list_users, which provides a helpful prerequisite. It does not exclude alternative tools, but the purpose is unambiguous enough that an agent can decide when to invoke 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?
Annotations already declare readOnly=true and destructive=false. The description adds useful behavioral context: parallel fetching, up to 10, and partial results with errors array including status_code. This goes beyond annotations, though it doesn't elaborate on rate limits or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with a distinct purpose—capability, use-case, limitation, and error behavior. No redundant 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 read-only, single-parameter tool with an output schema, the description is complete: it covers purpose, usage boundaries, and error handling. The output schema covers return value shapes.
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 parameter documentation (max 10, duplicates ignored), so the description adds little beyond restating 'by slug'. 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 tool fetches candidate details by slug, with a specific limit and parallel execution. This distinguishes it from sibling search_candidates and list_candidates, which handle broader discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states suitability for retrieving specific records after slug resolution from search_candidates and excludes bulk database scans, giving clear when-to-use and when-not-to-use 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context: parallel fetching and partial result reporting with an errors array containing status_code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, usage, and failure behavior. No fluff, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, high schema coverage, an output schema, and read-only annotations, the description covers the essential context. It includes when to use, limitations, and error handling, making it complete for this tool's 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 description coverage is 100% for contact_slugs, already defining max items, duplicate handling, and type. The description's mention of 'up to 10' and 'by slug' adds no new semantic 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 starts with a specific verb and resource: 'Fetches full details for up to 10 contacts in parallel by slug.' It clearly distinguishes from sibling tools like search_contacts (which resolves slugs) and list_contacts (which lists contacts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('after slug resolution from search_contacts'), when not to use ('Not intended for bulk database scans'), and names the alternative search_contacts. This gives clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds value by disclosing that returned records omit email, phone, resume, and profile image fields, which is behavioral context beyond the 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 core purpose, then usage guidance, then output limitation. No filler or redundant phrasing; each clause 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?
For a simple read-only lookup with two parameters and an output schema, the description covers purpose, parameter behavior, and a key output detail. It is sufficient for an agent to select and invoke the tool 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% with descriptions for both params. The description goes further by explaining the directional relationship in plain language ('Set entity_type to candidate to return contacts for a candidate slug, or contact to return candidates for a contact slug'), adding meaning beyond the terse schema 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 'Fetches contacts where a candidate is pitched or candidates pitched to a contact,' which clearly names the resource and bidirectional nature. It also distinguishes from sibling tools like get_pitch_history by specifying that it returns compact records and requires an entity_type and entity_slug.
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 instructs how to set entity_type to candidate or contact and what each returns, providing clear context for using the tool. It does not explicitly name alternatives or state when not to use it, but the compact record notice hints that full-field tools might be preferred when those fields are needed.
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?
The annotations already declare read-only and non-destructive behavior. The description adds valuable context about the response format, specifically noting that it returns compact pitch entries without email, phone, resume, or profile image fields, which helps set expectations beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions 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, consisting of two sentences that front-load the core purpose and then provide essential parameter and response details. Every sentence contributes value without unnecessary verbosity.
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 read-only lookup with two parameters and an output schema, the description is sufficiently complete. It covers the purpose, parameter behavior, and response characteristics, and no significant gaps are apparent for an AI 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters, achieving 100% coverage. The description further clarifies parameter semantics by explicitly stating that entity_type determines whether the lookup is for a candidate or contact, and that the lookup is performed by slug, adding meaningful guidance beyond the raw 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 fetches pitch history for a single candidate or contact by slug, using the specific verb 'Fetches' and identifying the resource as 'pitch history'. It distinguishes itself from sibling tools like get_candidate_details or get_pitched_records by focusing on pitch history for one entity.
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 explains how to use the entity_type parameter to choose between candidate and contact pitch history, providing clear context for when to use this tool. However, it does not explicitly mention alternative tools or when not to use this tool, so it stops short of full usage 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?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds value by revealing the output shape ('compact id/label rows') and its downstream use, which goes beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The description front-loads the core action and result, then adds a single actionable usage hint. Every word 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?
Given the simple list operation, the presence of an output schema, and strong annotations, the description is complete. It tells the agent what the tool returns and how to use that result, leaving no ambiguity.
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 trivially 100%. The description does not need to explain parameters, and the baseline of 4 applies for parameterless tools.
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 ('Lists') and resource ('Recruit CRM custom call types'), and it adds the output format ('compact id/label rows'). The mention of 'custom_call_type_id' distinguishes it from sibling type-listing tools by linking it to create_call_log.
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: it tells the agent to use the returned 'custom_call_type_id' in 'create_call_log'. This is a practical usage guideline, though it does not explicitly contrast with alternative tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: returns 'compact stage rows' for ID resolution and clarifies the default pipeline behavior. It does not disclose pagination or error handling, but for a simple read-only list with rich annotations, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions 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 long, front-loaded with the core purpose, and every sentence contributes new information. No fluff or redundancy, earning a perfect score.
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 one optional parameter and an output schema, the description covers purpose, usage guidance, parameter context, and downstream consumers. It is complete for the tool's complexity, especially with the supporting schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the default value of 0 for the Master Pipeline. The description adds extra meaning by explaining how to obtain a job-specific pipeline ID via search_jobs or list_jobs, which is not in the schema. This is a meaningful addition beyond the structured field 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 clearly states a specific verb and resource: 'Lists Recruit CRM candidate hiring stages for a hiring pipeline' and adds the purpose 'returning compact stage rows for resolving labels to stage IDs.' It distinguishes itself from sibling tools like list_hiring_pipelines by focusing on stages within a pipeline, not pipelines themselves.
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 context: passing hiring_pipeline_id 0 for the Master Pipeline and using the pipeline ID from search_jobs or list_jobs for job-specific stages. It also explains how stage IDs are used in other tools. It does not explicitly state when not to use the tool (e.g., vs. list_hiring_pipelines), but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral details beyond annotations: it mentions the default sort order ('most-recently updated first') and the return content ('compact summaries with slug and contact_slugs values'), providing transparency about what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions 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 every sentence adds value: the first explains what it lists and the ordering, the second describes the return format and points to an alternative for filtered queries. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and annotations, the description covers the key aspects: what it lists, the ordering, the return summary fields, and when to use an alternative. There are no obvious gaps that would prevent an agent from using it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described (page, limit, sort_by, sort_order). The description adds minimal parameter-specific meaning; it reiterates the default sort behavior already specified in the schema ('most-recently updated first' corresponds to sort_by=updatedon and sort_order=desc), but does not go beyond that.
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 companies in the account and specifies the default ordering ('most-recently updated first'). It also distinguishes itself from sibling tool search_companies by explicitly directing filtered queries there, so there is no ambiguity about 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use search_companies for filtered queries,' which tells the agent when to choose this tool versus the alternative. It also implies this tool is for unfiltered listing, giving clear usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by noting the output format ('compact rows with stage_id and label') and its purpose as a mapping helper, which goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions 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 includes only essential information: what it lists, what it returns, and why it's used. No redundant 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 zero-parameter list tool with an output schema, the description fully covers its role: it names the resource, clarifies the pipeline type, describes the return rows, and states the practical use (resolving stage names to IDs for other tools). This is complete for the tool's simplicity.
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 provides no parameter details, but none are needed; the schema is empty and coverage is 100% vacuously. The description's focus on the output and use case 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 it 'Lists Recruit CRM contact pipeline stages' with the clarifying parenthetical '(the sales pipeline)', identifying the exact resource and verb. It further differentiates from sibling tools by noting the stage_id is the one 'used in create_contact and update_contact', distinguishing it from hiring pipelines, pitch stages, and job statuses.
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 describes the intended use case: 'for resolving a stage name to the numeric stage_id used in create_contact and update_contact.' This provides clear context on when to invoke the tool, though it does not mention alternative tools explicitly or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context about MCP-side pagination and the fact that the underlying Recruit CRM endpoint returns all rows, explaining why pagination parameters exist. This goes beyond what annotations provide without contradicting them.
Agents need to know what a tool does to the world before 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 verb and resource, and every clause adds information (pagination, return fields, use cases). No filler or redundant content.
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 low-complexity list tool with an output schema, the description fully captures purpose, return fields, and usage intent. It is complete enough for an agent to select and invoke this tool correctly without further documentation.
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% with detailed descriptions for page and limit. The description reinforces the pagination context and links parameters to the tool's purpose (selecting pipelines/stages), adding a usage framing beyond the raw schema definitions.
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 ('Lists') with a clear resource ('Recruit CRM hiring pipelines') and adds scope ('with MCP-side pagination'). It also states the returned fields and intended use ('selecting a job hiring pipeline or listing candidate hiring stages'), fully distinguishing it from siblings like list_candidate_hiring_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?
The description indicates when to use the tool ('for selecting a job hiring pipeline or listing candidate hiring stages'), establishing clear context. It does not explicitly name alternatives or exclusion conditions, but the purpose-driven guidance is sufficient for this simple list 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?
The description adds behavioral context beyond the readOnlyHint and non-destructive annotations by disclosing the default sort order ('most-recently updated first') and the specific return fields (slug, company_slug, contact_slug, hiring_pipeline_id). This is useful practical information, though it does not mention pagination specifics, which are already covered in the schema and output 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 concise and well-structured: the first sentence states the primary purpose and default ordering, the second covers return fields and usage alternatives. Every sentence contributes useful information without 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?
The description covers scope (all jobs in account), default ordering, return shape, and alternatives, which is comprehensive for a read-only listing tool with no required parameters and a full output schema. It provides enough context for an agent to select and invoke 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?
The input schema already provides 100% coverage for all four parameters with detailed descriptions, so the baseline is 3. The description does not add new parameter-specific semantics beyond what the schema provides, as it focuses on the overall behavior and return shape.
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 jobs in the account, with a specific verb and resource. It also distinguishes itself from search_jobs by explicitly noting that filtered queries should use search_jobs, providing clear 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 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 search_jobs for filtered queries, and use hiring_pipeline_id with list_candidate_hiring_stages for job-specific stage lookup. This tells the agent exactly when to use this tool versus 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context beyond annotations: it returns 'compact rows' with 'id and label' and includes custom statuses. This tells the agent the output shape and scope. No contradictions with 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. The first sentence opens with a clear verb and resource, the second explains the return format and its purpose. Every word adds value, with no repetition of schema or annotation info.
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 (0 parameters, output schema present, no nested objects), the description fully covers what an agent needs to know: what statuses are listed, that they include custom ones, and the return format (id and label) for downstream use with search_jobs. There are no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is 100% (vacuously). Per the rubric, 0 params get a baseline of 4. The description doesn't need to add parameter details since there are none, and it correctly focuses on return value 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?
The description clearly states the tool's function with a specific verb and resource: 'Lists Recruit CRM job pipeline statuses'. It provides concrete examples (Open, Closed, On Hold) and notes custom statuses, making it distinct from sibling tools like list_hiring_pipelines. It also mentions the output fields, adding clarity.
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 the tool: to resolve a status name to the numeric job_status_id used in search_jobs.job_status. It doesn't explicitly exclude alternatives, but it positions the tool as a lookup utility, which is sufficient for the simple zero-parameter nature of the 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by mentioning the output is compact id/label rows, which is beyond the annotations. It does not overload with unnecessary details; the tool's simplicity is well captured.
Agents need to know what a tool does to the world before calling it. Descriptions 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 the core action and output format front-loaded. Every word adds value; there is no filler or redundant repetition of schema 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?
The tool has no parameters and an output schema, so the description does not need to explain return values. The description covers the resource, output shape, and how to use the result, making it self-sufficient for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline per the rubric is 4. The description does not need to elaborate further on parameters. It does hint at how the output is used (meeting_type_id), which adds a subtle semantic link.
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 Recruit CRM meeting types, uses a specific verb ('Lists') and a specific resource ('meeting types'), and adds the return format of compact id/label rows. It also distinguishes itself from siblings like list_call_types by focusing on meeting types.
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 tells the agent to use meeting_type_id from this tool in create_meeting, providing a clear use case. While it does not explicitly state when not to use it or name alternatives, the context is sufficient for an agent to infer when this reference list is needed.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. Beyond those, the description adds value by specifying the return format ('compact id/label rows'), which helps set expectations. There is no additional side-effect info needed for a read-only 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 sentence front-loads the action and resource, and the second sentence explains downstream usage. No filler or redundancy exists.
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?
The tool is simple with zero parameters, an output schema exists, and annotations provide safety hints. The description covers what the tool returns and how to use the result. No additional context is needed.
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 empty. Per guideline, 0 parameters yields a baseline of 4. The description adds meaningful context by mentioning note_type_id, which is likely a field in the output that can be used elsewhere, but it does not compensate for parameter details 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 explicitly states the verb 'Lists' with the resource 'Recruit CRM note types' and adds output detail. It clearly differentiates from sibling list tools by focusing on the specific resource and noting it returns compact id/label rows.
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: 'Use note_type_id in create_note', which tells the agent when to use this tool (when needing a note type ID for creating a note). It does not explicitly mention alternatives/purpose exclusions, but the referral to create_note gives sufficient usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context by noting it 'Returns compact rows with id, label, sequence_no, and default,' and specifies these are account-level configurations. No contradiction with 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 with no filler. It leads with the main action and provides essential details about return fields and usage, earning each word.
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, no-parameter read-only list tool with an output schema and rich annotations, the description fully covers purpose, return semantics, and usage context. Nothing critical is missing.
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 does not need to explain parameters, and it effectively adds no parameter-related information, 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's purpose: 'Lists Recruit CRM off-limit statuses configured for the account.' It uses a specific verb ('Lists') and resource ('off-limit statuses'), and adds context about being used for 'resolving status_id values used by the off-limit mark tools,' distinguishing it 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 implies when to use the tool: when needing to resolve status_id values for off-limit marking operations. It mentions the connection to 'off-limit mark tools,' providing clear context, though it does not explicitly list alternatives or 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?
Annotations already indicate a safe read operation, and the description adds valuable context: pagination is performed by the MCP server because the underlying metadata endpoint returns all rows. This explains a non-obvious behavior, though it doesn't disclose other potential caveats.
Agents need to know what a tool does to the world before 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 include essential details without redundancy. Every word earns its place, and the structure is highly scannable.
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, the presence of a full output schema, and annotations covering safety, the description adequately covers return values and behavioral context. No additional information is necessary.
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 already fully cover both parameters, so the baseline is 3. The description adds meaning by explaining why pagination exists and that it is MCP-side, which enhances understanding of the page/limit parameters 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 lists Recruit CRM qualifications, specifies MCP-side pagination, and details the return fields (qualification_id, label) and their purpose for job qualification_id fields. This verb+resource+scope formulation distinguishes it 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting the results are used for job qualification_id fields, implying when this tool is appropriate. However, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the output format (compact id/label rows) and noting the usage for create_task, which enriches behavioral understanding beyond the 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, front-loaded with the primary purpose, and every sentence adds essential information: output format and usage tie-in. There is 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?
For a simple, parameterless, read-only list tool with an output schema, the description provides complete context: what it lists, the return format, and how the output is used downstream. No additional details are needed 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The description adds no parameter specifics, but the baseline for zero-parameter tools is 4, and the description appropriately focuses on output and usage rather than unnecessary 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 lists Recruit CRM task types and returns compact id/label rows. This specific verb+resource combination distinguishes it from similar list tools like list_call_types and list_note_types.
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 indicating the task_type_id is used in create_task, which implies when this tool is useful. It does not explicitly exclude alternatives, but the purpose is clear enough to differentiate from sibling list tools.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds important behavioral context: it removes the off-limit state, optionally cascades to related contacts/candidates for companies, and discloses return values including cascade flags. This goes well beyond the 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, front-loaded with purpose, and every clause adds value (scope, parameters, conditional behavior, return fields). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, conditional logic) and that an output schema exists, the description covers purpose, required parameters, conditional behavior, and return values. It is sufficiently complete for an agent to select and invoke the tool 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 baseline is 3. The description adds meaningful information by stating that mark_contact_available and mark_candidate_available are required when record_type=company, which is not explicit in the schema (they are only described as 'whether' flags). This clarifies conditional requirement.
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 'Marks Recruit CRM candidates, contacts, or companies as available, which removes their off-limit state.' This is a specific verb-resource pair that distinguishes it from siblings like mark_candidate_off_limit, mark_contact_off_limit, and mark_company_off_limit.
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 clear prerequisites and conditional behavior (requires record_type and slugs; for company type, cascade flags are needed) but does not explicitly contrast with alternative tools or state when not to use it. Usage is implied rather than directly compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavior beyond that: it returns compact summaries, and explains how related_to and related_to_type can be used in app URLs. This gives the agent insight into output meaning and follow-up actions.
Agents need to know what a tool does to the world before 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 focused sentences. The first states purpose; the second gives a key filter guidance; the third explains output usage. No filler 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?
With 13 optional parameters, an output schema, and read-only annotations, the description covers the essential guidance: handling large result sets, filtering by owner, and using related entity fields. The existence of an output schema means return values need not be described. This is complete for the tool's complexity.
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 the baseline is 3. The description adds value by highlighting owner_id with a concrete use case (scoping to a user) and pointing to list_users for ID resolution. It also clarifies the paired usage of related_to and related_to_type, which is helpful 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 clear verb and resource: 'Search Recruit CRM meetings'. It also specifies the output type ('compact summaries designed for large result sets'), which distinguishes it from mutation tools like create_meeting and update_meeting.
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 practical usage context, advising to filter by owner_id and resolve IDs via list_users. It also implies this tool is for large result sets ('compact summaries'). However, it does not explicitly name alternatives or exclusion conditions, 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not need to restate that this is a mutation. It adds useful behavioral context by noting that calendar invites are not sent by default and that setting do_not_send_calendar_invites to false will send them, plus the requirement to provide at least one field to update. This adds value beyond the structured 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 three sentences long, all information-dense with no filler. It front-loads the purpose and then packs prerequisites, ID resolution pointers, calendar invite behavior, and return value into a compact structure. 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?
Given the tool's complexity (24 parameters), the schema fully describes all parameters, an output schema exists, and annotations cover mutability/destructive hints. The description adds the essential operational context: required fields, ID resolution, and the calendar invite default. It is complete enough for an agent to select and invoke 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?
The input schema has 100% coverage of all 24 parameters with detailed descriptions, so the baseline is 3. The description adds a cross-parameter constraint ('at least one field to update') and references external tools for resolving certain IDs, but this is limited additional meaning 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 'Updates one existing Recruit CRM meeting by meeting_id.' It specifies the verb (updates), the resource (Recruit CRM meeting), and the scope (one existing by meeting_id). This distinguishes it from create_meeting and search_meetings, which are sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states prerequisites: 'Requires meeting_id, updated_by, and at least one field to update.' It also directs users to sibling tools for resolving IDs ('Resolve meeting type IDs with list_meeting_types and user IDs with list_users'), and explains how to control calendar invite behavior. This provides clear when-to-use and how-to-use 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?
The description adds context beyond annotations by stating that it returns a compact call log summary with duration in seconds, and it clarifies that the call type and user IDs must be resolved beforehand. No contradiction with the destructiveHint=true annotation is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each providing necessary information: creation, required fields, lookup guidance, and response format. 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?
Given the tool's 18 parameters and 6 required fields, the description covers the critical required fields, lookup dependencies, and return value. The schema and output schema handle optional fields and detailed structures, so the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by naming which tools to use for resolving custom_call_type_id and user IDs, and by reinforcing the allowed related_to_type values. It does not repeat every parameter description but supplements the schema where lookups are 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 'Creates' and identifies the resource as 'one Recruit CRM call log', clearly distinguishing it from sibling tools like update_call_log and search_call_logs. The singular 'one' clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool by stating required fields and directing the agent to resolve call type IDs with list_call_types and user IDs with list_users. It also sets the constraint for related_to_type values, which is actionable guidance.
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 though annotations already mark readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral detail: API call counts (~7 baseline, +25–55 with time metrics), the data source for days_in_current_stage (stage_date), auto-skipping of include_activity when start_page > 1, and capping of fetched candidates. These are valuable operational facts not visible in 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 dense but well-organized: main purpose first, then optional metrics, prerequisite, linking convention, and a final limitation. Every sentence contributes useful information without 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?
For a tool with 8 parameters, an output schema, and a complex analysis workflow, the description covers purpose, usage context, behavioral costs, prerequisites, optional extensions, and limitations. It is fully sufficient for an agent to decide when to use it and what to expect.
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% parameter coverage with detailed descriptions (defaults, behavior, cost implications). The main description adds minimal semantic meaning beyond the schema—though it does contextualize include_time_metrics and API call trade-offs, it largely restates what the schema already documents. 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 opens with a specific verb and resource: 'Diagnoses a single Recruit CRM job's hiring pipeline.' It enumerates concrete outputs (stage-by-stage candidate distribution, days_in_current_stage, idle/at-risk candidates, bottleneck verdict, notes/meetings/tasks, next actions), which clearly distinguishes it from sibling tools like search_jobs or get_job_assigned_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: it requires a job_slug and instructs to 'resolve from search_jobs if only a job name is available.' It also states a limitation and exclusion: 'Call logs are not included because the Recruit CRM API does not support filtering call logs by job.' This helps the agent understand scope and alternatives.
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?
Beyond annotations (readOnlyHint=true, destructiveHint=false), the description discloses that calls run in parallel for up to 10 companies and that partial failures return an errors array with status_code. This adds valuable context about concurrency and error behavior not visible in 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?
Three sentences efficiently cover purpose, usage, and error behavior without redundancy. The key action is front-loaded, and every sentence adds informational 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?
Given the tool's simplicity (one parameter, output schema present, read-only annotations), the description fully covers parallel fetching, partial results, and usage context. No additional behavioral detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter info, including min/max items, uniqueness, and a description of company_slugs. The description adds no additional parameter details beyond what the schema already 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 fetches full details for up to 10 companies by slug, distinguishing it from search_companies (which resolves slugs) and list_companies (bulk scans). The verb 'fetches' plus resource 'company details' makes 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use (after slug resolution from search_companies) and when not to use (bulk database scans), giving clear guidance on alternatives. The mention of partial results also sets expectations for error handling.
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?
While annotations already mark it as non-destructive/read-only, the description adds critical behavioral details: parallel fetching, partial results with an errors array, and status_code reporting for failures. This goes beyond the annotations and gives the agent an accurate model of success/failure 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?
Two sentences achieve high information density without waste. The first sentence states the core function and limits; the second adds the use case, result behavior, and error reporting. Information is front-loaded and every clause 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?
For a single-parameter read tool with an output schema, the description is complete: it explains the input (slugs), the workflow prerequisite (search_jobs), the parallelism and size limits, and the partial-failure semantics. No gap remains for an agent to safely invoke the 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 provides 100% coverage of the single parameter (job_slugs) with constraints and duplicate-ignoring behavior. The description adds only contextual linkage to search_jobs, but no additional parameter-specific semantics beyond what the schema already offers. Baseline of 3 is appropriate given 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 a specific verb ('fetches') and resource ('full details for up to 10 Recruit CRM jobs in parallel by slug'). It distinguishes from sibling search tools by specifying the exact entry point (slug) and scope (full details, specific records), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Suitable for retrieving specific job records after slug resolution from search_jobs', providing clear when-to-use context and pointing to the prerequisite tool. It also communicates the capacity limit (up to 10), helping agents decide when to batch or paginate.
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?
Beyond the readOnlyHint=false and destructiveHint=true annotations, the description details duplicate-check behavior (by email, contact_number, linkedin), error payload contents (candidate_slug, candidate_id), file-acceptance rules (URL or base64 for resume, URL-only for custom file fields), and return behavior (compact summary with partial-success details). This goes well beyond the annotations.
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 dense paragraph that front-loads the core purpose and then covers prerequisites, duplicate handling, ID resolution, and file rules. It is appropriately sized for a complex 44-parameter tool, but could benefit from bullet points or sectioning for easier scanning.
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 high parameter count and existing output schema, the description covers all critical operational aspects: field requirements, duplicate policy, file constraints, ID resolution, and response summary. It provides enough context for an agent to invoke the tool correctly without needing to consult external documentation.
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%, but the description adds meaningful cross-references for resolving parameter values (e.g., language_skills with list_languages_and_proficiencies, custom field IDs with list_custom_fields). It also reinforces required fields and file-type restrictions, adding value beyond the schema 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 specific verb and resource: 'Creates one Recruit CRM candidate'. It clearly distinguishes itself from siblings like update_candidate and search_candidates by specifying the creation action and the optional work/education history creation.
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?
It explicitly states prerequisites ('Requires at least one of first_name or last_name, plus owner_id and created_by') and provides direct guidance on resolving IDs via sibling tools (list_users, list_currencies, etc.). It also clarifies when duplicates are allowed ('unless allow_duplicate=true'), giving clear use conditions.
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?
Annotations already convey the tool is not read-only and has destructive/world-changing potential. The description adds concrete behavioral details beyond annotations: specific defaults (enable_auto_populate_teams=true, show_company_logo=2), the return format (compact summary with job slug), and live-API-verified optionality. No contradiction with annotations.
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 dense but each sentence serves a purpose. It front-loads the primary action, then lists required and optional fields, and ends with a compact reference list. While long, it avoids filler and is efficiently organized for an agent parsing it.
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 complexity (42 params, nested objects) and the existence of an output schema, the description sufficiently covers prerequisites, defaults, reference tools, and return value. It tells the agent exactly what is required and where to find supporting data, making it complete for correct selection and 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?
Schema descriptions cover 100% of parameters, but the description adds value by mapping parameters to external reference tools (e.g., list_users for owner_id) and by stating defaults that are not in the schema (e.g., show_company_logo defaults to 2). This goes beyond the schema's individual property 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 'Creates one Recruit CRM job', which is a specific verb + resource that clearly distinguishes this tool from sibling tools like update_job, search_jobs, and list_jobs. It also enumerates the required fields, leaving no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives by linking each parameter to the correct lookup tool (e.g., 'Use list_users for user IDs', 'search_companies or list_companies for company slugs'). It also clarifies optional fields and defaults, giving the agent a complete decision path for invocation.
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?
Annotations already declare readOnlyHint and destructiveHint, so safety is covered. The description adds valuable behavioral context: MCP-side pagination, default fields, and the effect of expand and include_user_contact_info. This goes beyond the structured annotations and schema descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions 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 every clause provides essential 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with an output schema, the description covers all key aspects: what it returns, how pagination works, and how to expand results. The output schema handles return details, so no further completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description further explains parameter behavior, especially the interplay between expand and include_user_contact_info, as well as the pagination rationale. This adds meaning beyond the schema's individual property 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 tool 'Lists Recruit CRM teams with MCP-side pagination', specifying the resource (Recruit CRM teams) and the action (list). It also distinguishes from siblings like list_users or list_candidates by focusing on teams and detailing return fields.
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 on what the tool does and how to customize output via expand and include_user_contact_info, but it does not explicitly mention when to use it over alternative list tools. Implied usage is sufficient for an agent, but no exclusions or named alternatives are provided.
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?
While annotations indicate read-only safety, the description adds valuable behavioral context: broad searches return compact summaries with only related_count, and name-filtered searches return related_slugs. It also discloses the owner-filtering limitation, which is not captured in annotations. No contradictions with the annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: identification, requirement, limitation, and conditional behavior. It is front-loaded with the core purpose and avoids any redundant phrasing. 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?
Given the tool's moderate complexity, the description covers essential usage conditions (required field, unsupported filtering) and return behavior (compact summaries vs. enriched results). The presence of an output schema offloads detailed return formatting, so the description is sufficiently complete for correct tool 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?
Schema coverage is 100%, so the baseline is 3. The description adds semantic value beyond the schema by explaining the behavioral consequence of providing the 'name' parameter (inclusion of related_slugs) and characterizing 'shared' as a filter. This additional context earns a 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 action ('Search Recruit CRM hotlists') and the primary filtering dimension ('by related_to_type and optional name/shared filters'). It distinguishes itself from sibling search tools by focusing specifically on hotlists and explicitly noting it does not support owner filtering, which is a differentiator.
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?
Provides explicit when-to-use guidance: 'related_to_type is required' sets the precondition, and 'When name is provided, results also include related_slugs for follow-up workflows' indicates a specific use case. The exclusion 'Does not support owner filtering' clearly tells the agent when not to use this tool for owner-based queries.
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-recruitcrm MCP server](https://glama.ai/mcp/servers/Workforce-Cloud-Tech/mcp-recruitcrm/badges/card.svg)](https://glama.ai/mcp/servers/Workforce-Cloud-Tech/mcp-recruitcrm)

Score Badge

Copy to your README.md:

[![mcp-recruitcrm MCP server](https://glama.ai/mcp/servers/Workforce-Cloud-Tech/mcp-recruitcrm/badges/score.svg)](https://glama.ai/mcp/servers/Workforce-Cloud-Tech/mcp-recruitcrm)

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/Workforce-Cloud-Tech/mcp-recruitcrm'

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