queryquarry
Server Details
Double-blind talent marketplace: AIs search anonymous opted-in candidates; reveal on consent.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- QueryQuarry/QueryQuarry
- GitHub Stars
- 0
- Server Listing
- QueryQuarry
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 11 of 11 tools scored. Lowest: 2.7/5.
Each tool targets a distinct operation: subscription, candidate search, detailed view, contact management, stats, docs, new candidates, watchlist, outcome reporting, and saving. No two tools overlap in purpose; the descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_subscription, get_candidate, search_candidates). The verbs vary as needed for different actions, maintaining a predictable structure.
With 11 tools, the set is well-scoped for a candidate sourcing platform. It covers search, detailed viewing, contact, watchlist management, subscription, and documentation without being excessive or too sparse.
Core workflows are covered: search, view, request contact, report outcome, save to watchlist. Minor gaps exist, such as lacking a remove-from-watchlist tool or a way to cancel a contact request, but these do not severely hinder the main use case.
Available Tools
11 toolscheck_subscriptionARead-onlyInspect
Check your subscription tier, status, rate limit, and usage this hour.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; the description adds value by listing return fields (tier, status, rate limit, usage). No contradictions. For a simple read tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loads the action and key outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and simple read-only nature, the description fully covers what the tool does and returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Per guidelines, baseline is 4. Description adds no extra param info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('subscription'), listing specific attributes (tier, status, rate limit, usage). It clearly distinguishes from sibling tools, none of which are subscription-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to check own subscription) and is straightforward with no parameters. However, it does not explicitly state when not to use or provide alternatives, though none exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_candidateARead-onlyInspect
Evaluate one candidate in depth — full skills, summary, seniority, experience (titles + what they did) and education. Stays ANONYMOUS: no name, no contact, and employer names, dates, and graduation years are withheld to protect identity. Counts toward your hourly/daily reveal limit. To actually reach someone, call request_contact.
| Name | Required | Description | Default |
|---|---|---|---|
| resume_id | Yes | ||
| candidate_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), description adds key trait: anonymity (no name, contact, employer names, dates, graduation years). Also mentions reveal limit. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, anonymity, usage limit + alternative. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers purpose, usage, and transparency well. Lacks detail on output format but sufficient for an agent to select and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description does not explain what resume_id and candidate_id represent or how to obtain them. Minimal addition over schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'evaluate' and resource 'candidate in depth', listing specific fields (skills, summary, seniority, experience, education). It distinguishes from sibling tools like get_contact and search_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (in-depth evaluation) and when not to (to reach someone, call request_contact). Also notes count toward reveal limit, guiding agent on cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contactARead-onlyInspect
Check the status of a contact request you sent: sent (awaiting), accepted (the candidate shared their contact — see shared_contact, and expect their intro email quoting the code), or declined. Identify it by contact_id or code. Also shows any hire outcome either side reported.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| contact_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint annotation, detailing what information is available (status, hire outcome) and what to expect when accepted (shared_contact, intro email). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, front-loaded with purpose, and uses no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description adequately covers the purpose, identification methods, possible statuses, and additional outcome information, making it complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the parameters (code, contact_id) lack schema-level descriptions. The tool description explains that identification is by contact_id or code, but does not provide additional details like format, constraints, or which to prefer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of a contact request you sent, listing specific statuses (sent, accepted, declined) and additional hire outcome information. It distinguishes from sibling tools like request_contact and report_contact_outcome by focusing on checking status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 and implies alternatives through sibling tool names, but it does not explicitly state when not to use this tool or directly compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_corpus_statsARead-onlyInspect
Get aggregate stats about the talent corpus (counts, top skills/locations).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates safe read behavior. The description adds minimal extra behavioral context (that it returns counts and top skills/locations), but does not disclose details like data freshness, pagination, or potential delays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundancy. All words contribute meaning, and the description is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool returning simple aggregate stats, the description is sufficient. It names the output components (counts, top skills/locations). However, it could mention any constraints like data recency or scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema fully covers the input. The description does not need to add parameter details, and its brief mention of output fields aligns with the schema's emptiness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves aggregate stats from the talent corpus, specifying counts and top skills/locations. It distinguishes itself from siblings like get_candidate and get_contact, which fetch individual entities rather than corpus-level aggregates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining corpus-level statistics, and the tool's name and context signal its non-invasiveness. However, no explicit guidance on when to use alternatives is provided, though the distinction is clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_docsARead-onlyInspect
Get the full QueryQuarry reference (how it works, all tools and filters, search tips, rate limits, privacy). Call this when you need detail beyond these tool descriptions, when guiding a new user, or before composing a complex search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that the tool returns a reference document, which is consistent. No further behavioral traits (e.g., rate limits or data freshness) are mentioned, but the description is adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and usage guidelines. No unnecessary words or details. It earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, clear purpose), the description fully covers what the agent needs to know: what is returned and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per guidelines baseline is 4. The description does not add parameter information because none exist; this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'the full QueryQuarry reference' including specifics like how it works, tools, filters, search tips, rate limits, and privacy. This is a specific verb+resource combination that distinguishes it from sibling tools like get_candidate or get_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling this tool 'when you need detail beyond these tool descriptions, when guiding a new user, or before composing a complex search.' While it provides clear context, it does not mention exclusions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_new_candidatesARead-onlyInspect
Get resumes new or updated since a timestamp (your standing alert). Same filters as search_candidates. Call daily with yesterday's timestamp; no duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | ISO timestamp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint: true); description adds context about deduplication and personal alert, enhancing transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains what the tool does and its relation to search_candidates, second provides usage instruction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully covers purpose, usage, and parameter meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description of 'ISO timestamp' parameter. Description adds no extra semantic detail beyond that, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves resumes new or updated since a timestamp, distinguishing it from sibling tool 'search_candidates' by mentioning 'your standing alert' and 'same filters as search_candidates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call daily with yesterday's timestamp and notes no duplicates, providing clear when-to-use guidance and implicit alternative via 'same filters as search_candidates'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_watchlistCRead-onlyInspect
Get your saved candidates (watchlist).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| status | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds no further behavioral context beyond confirming it retrieves data, which is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it lacks structure. It could include a brief parameter summary or usage hint without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain return format, pagination, or filtering behavior. For a list retrieval tool with sibling tools, this context is missing, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description offers no explanation for the 'page' or 'status' parameters. Without parameter guidance, the agent cannot use the tool effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves saved candidates (watchlist). It is specific about the resource and action, but does not differentiate from sibling tools like get_candidate (singular) and get_new_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context about prerequisites or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_contact_outcomeAIdempotentInspect
One-tap outcome report on an accepted contact: did it lead to a hire? Optional but appreciated — it's how the marketplace measures that consented outreach beats cold outreach. Values: hired | not_hired | in_progress.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| outcome | Yes | ||
| contact_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds that it is a 'One-tap outcome report,' implying a quick, non-destructive action. No additional behavioral traits (e.g., permissions, side effects) are disclosed, but annotations cover the key aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every word adds value. No repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description fails to explain the 'code' and 'contact_id' parameters, nor does it specify that contact_id is likely needed to identify which contact. It also does not mention what the tool returns or effects beyond recording.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only adds meaning for the 'outcome' parameter by listing its enum values. The 'code' and 'contact_id' parameters are not explained, leaving ambiguity about their purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('report outcome'), the resource ('accepted contact'), and the precise question ('did it lead to a hire?'). It also lists the allowed values, making the purpose unambiguous. This tool is distinct from siblings like 'request_contact' or 'get_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that reporting is optional but appreciated, and provides context on why ('it's how the marketplace measures that consented outreach beats cold outreach'). It does not explicitly state when not to use this tool or name alternatives, but the context is clear enough for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_contactAInspect
Reach out to one candidate. You identify yourself (your name + company, from your account); the candidate is notified and decides. If they accept, you receive an EMAIL with their contact, their message, and a unique verification code — their identity stays private until they choose to share it. METERED (counts toward your contact limit) and requires a prior get_candidate for this resume. One active offer per candidate; respect declines. get_contact also shows the status any time.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Your pitch to the candidate: the role and why them. Your account email is AUTOMATICALLY attached and shown to them when they express interest, so you don't need to include it. You may optionally add other ways to connect (an application form link, your LinkedIn, etc.). Shown in-app, not your raw query. | |
| resume_id | Yes | ||
| candidate_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint: false, destructiveHint: false, openWorldHint: true), the description reveals that the action is metered, the candidate's identity remains private until they accept, and the user receives an email with a verification code. This adds critical behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, front-loading the core purpose. Every sentence provides actionable information (metered, prerequisite, one active offer, contact behavior). It could be slightly shorter but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters and no output schema, the description fully explains the flow: initiate contact, candidate decides, user receives email with details and code. It covers the entire interaction, leaving no significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33%, but the description compensates by explaining the 'message' parameter in detail—what to include, what is automatically added, and how it appears. It also implies the role of 'resume_id' and 'candidate_id' by referencing the prerequisite get_candidate call. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Reach out to one candidate,' a specific verb and resource. It clearly distinguishes from sibling tools like get_contact (status) and report_contact_outcome (reporting), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a prerequisite: 'requires a prior get_candidate for this resume.' It also mentions 'One active offer per candidate; respect declines,' guiding proper usage. However, it does not explicitly list when not to use or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_candidateAIdempotentInspect
Save a candidate resume to your watchlist with optional notes.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| resume_id | Yes | ||
| candidate_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false), not destructive, and idempotent. The description adds the context of 'to your watchlist with optional notes', which clarifies the outcome. However, it does not explain what happens if the candidate is already in the watchlist (e.g., update notes or no-op).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with 3 parameters, but it lacks information about return values (no output schema) and does not clarify the behavior when a candidate or resume already exists in the watchlist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should clarify parameter meanings. It only mentions 'optional notes' implicitly. The required parameters candidate_id and resume_id are not explained, such as what they represent or how to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Save) and the resource (candidate resume to watchlist) with optional notes. It is distinct from sibling tools like get_watchlist (viewing) and search_candidates (searching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to add a candidate to a watchlist, but it does not explicitly mention when to use this over other tools, such as when you already have the candidate saved or alternative actions like request_contact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_candidatesARead-onlyInspect
Search the talent graph. Returns ANONYMOUS match cards — headline, skills (with skills_matched showing which of YOUR terms hit), seniority, location, availability, salary range, and a short snippet — but NO name, full resume, or contact. Call get_candidate (a metered reveal) for the deeper anonymous profile. Filter by skills, location, seniority, salary, experience, availability, and more; sort by recency (default) or skill_match. Always paginated (max 25 per page).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page. | |
| sort | No | Result order. When `skills` are supplied the default is skill_match: candidates matching MORE of your skills terms first (ties by most recently updated) — pure arithmetic over your own criteria, no fit scoring. Pass "recency" to order purely by recent updates; searches without `skills` are always recency-ordered. | |
| limit | No | Results per page (max 25). | |
| skills | No | Skills to match (any of). Case-insensitive partial match — use plain terms like "React", "Node", "Postgres"; they also match versioned/variant skills ("React 19", "Node.js", "PostgreSQL"). | |
| location | No | City with state ("Schaumburg, IL") or a 5-digit zip ("60133" — most precise). Geocoded locally; combine with radius_miles for distance search. Unresolvable text falls back to substring match. | |
| remote_ok | No | Only candidates open to remote/hybrid. | |
| salary_max | No | ||
| salary_min | No | ||
| availability | No | ||
| radius_miles | No | With location: include candidates within this many miles (e.g. 5, 10, 25, 50; max 100). Omit for exact-place matching. | |
| updated_since | No | ISO timestamp — only resumes updated since. | |
| employment_types | No | Engagement types to match (any of): full-time, part-time, contract, freelance, internship. Synonyms/variants are normalized. | |
| seniority_levels | No | Seniority levels to match (any of): entry, junior, mid, senior, staff, principal, manager, director, executive. | |
| open_to_relocation | No | Only candidates willing to relocate for the right role. | |
| work_authorization | No | Filter by work authorization: "authorized" (no sponsorship needed) or "sponsorship-required". | |
| work_location_types | No | Work-location preferences to match (any of): remote, hybrid, onsite. | |
| experience_years_max | No | ||
| experience_years_min | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details that results are anonymous (no name, full resume, contact) and lists returned fields. It also mentions pagination and max 25 per page. Annotations already note readOnlyHint=true, and description adds significant behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences covering purpose, return details, and guidance. It is front-loaded with the action and returns. Slightly verbose on sorting details but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters and no output schema, the description adequately describes the return structure and filtering capabilities. It could mention that it searches only active candidates or provide more nuance, but it is largely complete for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 72%, so baseline is 3. The description summarizes filter categories but does not add substantial meaning beyond schema. It repeats some schema info (e.g., sort options) without detailing parameters like salary_min/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the talent graph' and specifies what is returned: anonymous match cards with headline, skills, etc. It distinguishes from sibling tool get_candidate, which returns a deeper profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use get_candidate for the deeper anonymous profile, implying search_candidates is for initial broad searches. It also describes filtering and sorting options, guiding when to apply each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.