queryquarry
Server Details
Double-blind talent marketplace: AIs search anonymous opted-in candidates; reveal on consent.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 10 of 10 tools scored. Lowest: 2.7/5.
Each tool has a clearly distinct purpose: account info, candidate search, detailed view, contact management, watchlist, stats, and documentation. No overlap or ambiguity between them.
All tools follow a consistent verb_noun pattern in snake_case (e.g., check_subscription, get_candidate, search_candidates). No mixing of conventions or vague verbs.
With 10 tools, the set is well-scoped for a candidate recruitment platform, covering search, details, contact, watchlist, account, stats, and help without excess or deficiency.
Core workflows are covered (search, view, contact, save, manage watchlist), but minor gaps exist: no tool to remove from watchlist or list all contact requests. These are not critical but noticeable.
Available Tools
10 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 is interested — they'll reach out to you directly, quoting the code), or declined. Identify it by contact_id or code.
| 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?
Annotations already declare readOnlyHint. Description adds meaning of statuses and that candidate will quote code. No contradiction. Provides 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Directly conveys essential information.
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?
Covers purpose, statuses, identification. No output schema, so description could mention return format, but implied. Slightly incomplete on output details.
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%; description adds that identification is by contact_id or code, giving purpose to both parameters. Does not specify format or constraints, but basic meaning is provided.
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?
Clear verb 'check' and resource 'status of a contact request you sent'. Distinguishes from siblings by specifying it's about sent contact requests and listing specific statuses (sent, accepted, declined).
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?
States when to use: to check status of contact request. Implies alternatives like request_contact for sending. Lacks explicit when-not-to-use, but context is clear.
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.
request_contactAInspect
Reach out to one candidate. You identify yourself (your name + company, from your account); the candidate is notified and decides. If they express interest, your account email + a unique code are shared with them and they reach out to you directly — their identity stays private until they choose to. METERED (counts toward your contact limit) and requires a prior get_candidate for this resume. One active offer per candidate; respect declines. Poll get_contact to see if they marked interest.
| 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?
The description discloses metering, identity-sharing mechanics, and prerequisite conditions, which go beyond the annotations (readOnlyHint=false, destructiveHint=false). It provides full transparency into the tool's behavior and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence for purpose, followed by key behavioral details. It is moderately concise; some redundancy could be trimmed but overall it is efficient and 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?
Given the tool's moderate complexity (3 required params, no output schema), the description covers all essential aspects: prerequisites, metering, state transitions, and agent actions. It leaves no ambiguity for correct usage.
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?
Although schema description coverage is only 33%, the tool description compensates by explaining the 'message' parameter in detail (pitch, auto-attached email) and contextualizes 'resume_id' and 'candidate_id' (requires prior get_candidate, one active offer).
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 'Reach out to one candidate' with a specific verb and resource. It distinguishes itself from sibling tools like get_candidate (viewing) and get_contact (checking status) by focusing on initiating 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?
Explicit guidelines include that it is metered, requires a prior get_candidate call, enforces one active offer per candidate, and advises respecting declines. It also instructs to poll get_contact to see if the candidate marked interest, providing actionable context.
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, seniority, location, availability, salary range, and a short snippet — but NO name, full resume, or contact. Call get_candidate (a metered reveal) to unlock a specific person's identity, full resume, and contact. Filter by skills, location, seniority, salary, experience, availability, and more. Always paginated (max 25 per page).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page. | |
| 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 adds substantial behavioral context beyond annotations. It details what the tool returns (anonymous match cards with specific fields), what it does NOT return (name, full resume, contact), filtering behaviors (case-insensitive partial match for skills, geocoding for location, pagination with max 25 per page). Annotations only indicate readOnlyHint: true, which is consistent.
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 paragraph that efficiently conveys key information. It front-loads the most important point (what is returned). It could be more structured (e.g., bullet points) but is concise given the amount of detail. No unnecessary sentences.
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 17 parameters and no output schema, the description covers the return format, filtering capabilities, and links to sibling tools. It explains the anonymous nature and how to get more details. However, it could mention error conditions or additional constraints. Overall, it provides sufficient context for an agent to use the tool effectively.
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 71% (12 of 17 parameters have descriptions). The description reinforces some parameter context (e.g., pagination for limit, geocoding for location) but does not add semantics for undocumented parameters like salary_max, salary_min, experience_years_max/min. Baseline 3 is appropriate as the description provides moderate added 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 clearly states the tool searches the talent graph and returns anonymous match cards with specific fields. It also distinguishes itself from sibling get_candidate by noting that get_candidate reveals identity. The verb 'search' and resource 'talent graph' are specific, and the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool vs. get_candidate: 'Call get_candidate (a metered reveal) to unlock a specific person's identity...' It also mentions pagination and filtering options. However, it does not explicitly state when not to use it or mention any prerequisites.
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!