talent
Server Details
Talent discovery for AI. Search and read agent-readable candidate profiles; cite by URL.
- 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 3.9/5 across 7 of 7 tools scored.
Tools are mostly distinct with clear descriptions. However, search and search_talent both search for talent, potentially causing confusion despite differing inputs and outputs. Also fetch and get_profile both retrieve full profiles, though fetch uses a handle from search and get_profile uses a handle directly.
Naming conventions are inconsistent: add_to_shortlist uses verb+preposition+noun, fetch is a bare verb, get_open_to_work and get_profile use get_, save_search uses save_, and search and search_talent are verbs. No uniform pattern.
Seven tools is appropriate for a talent search platform, covering key operations without being excessive or insufficient.
Core workflows like searching, retrieving profiles, shortlisting, and saving searches are covered. Potential gaps include updating or removing from shortlists, but the existing tools address main use cases.
Available Tools
7 toolsadd_to_shortlistAInspect
Add a candidate to one of your d.cv shortlists (creates the shortlist if it does not exist). Requires your d.cv API key. Use after search_talent when the user wants to save someone.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The candidate handle to add, e.g. "kukuh" | |
| shortlist | No | Shortlist name. Defaults to "From AI". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool can create a shortlist if it doesn't exist and requires an API key. However, it does not clarify behavior when the candidate already exists in the shortlist (e.g., duplicate handling, idempotency), leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the core action and side effect, then adds usage guidance and requirements. Every sentence earns its place.
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 low complexity (2 parameters, no output schema). The description covers the main action, side effect, requirement, and usage context. However, it omits potential details like return value or error conditions, and does not fully address duplicate behavior, limiting completeness for an 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 100%, so the schema already documents both parameters with examples. The tool description adds behavioral context about the shortlist being created if missing, which relates to the 'shortlist' parameter, but does not provide new syntactic or semantic details beyond what the schema covers. A baseline of 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?
The description uses a specific verb ('Add') and resource ('candidate to one of your d.cv shortlists'), explicitly states the side effect ('creates the shortlist if it does not exist'), and provides usage context ('Use after search_talent'). This clearly distinguishes it from siblings like 'save_search' or 'search_talent'.
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 states when to use ('after search_talent when the user wants to save someone') and a prerequisite ('Requires your d.cv API key'). It does not mention when not to use or provide alternative tools, 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.
fetchAInspect
Fetch a single d.cv profile in full as markdown, by its id (the handle returned from search).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The profile id / handle, e.g. "kukuh" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions output format (markdown) but does not disclose auth needs, error behavior, or rate limits, which are critical for read operations.
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 with no unnecessary words, front-loaded with action and resource.
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 one-parameter tool with clear schema, the description is adequate, but could mention more about the return format details or edge cases.
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% and description adds example 'kukuh' and source context, but schema already describes the parameter similarly; no additional semantic enrichment.
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 fetches a single d.cv profile in full as markdown by ID, which distinguishes it from siblings like search that likely return summaries or lists.
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 use after search by specifying the ID comes from search, but gives no explicit when-not or alternative tools guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_open_to_workAInspect
List candidates who are currently open to work, optionally filtered by skills. Best when the user wants people actively looking.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 25) | |
| skills | No | Optional skills/role to filter by |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states the core function. No mention of pagination, output format, or read-only nature. Adequate for a simple list tool but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the primary action, followed by usage guidance. Exemplary conciseness.
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?
Provides core purpose and usage hint but lacks details about return values (no output schema) and default behavior. Adequate for a simple tool but not fully complete.
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%, so baseline is 3. The description adds 'optionally filtered by skills' which mirrors the schema. No additional parameter details or constraints beyond what schema provides.
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?
Clearly states the tool lists candidates who are open to work, with optional skill filtering. Distinguishes from siblings like search_talent by focusing on actively looking 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 indicates 'Best when the user wants people actively looking,' guiding when to use. Could mention when not to use or compare directly with search_talent, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileAInspect
Read a single candidate profile in full as clean markdown, by handle.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The profile handle, e.g. "kukuh" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is a read operation (non-destructive) and specifies the output format as clean markdown. However, it does not cover potential edge cases like missing handle or authorization requirements, but given simple read behavior, it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word adds value, and the structure is optimal.
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 covers the essential purpose and output format. It could mention behavior when handle is invalid, but it is largely complete.
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 one parameter; the description adds context that the output is markdown, which goes beyond the schema. However, it does not provide additional details about the parameter itself beyond what the schema already says.
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 (Read), the resource (single candidate profile), the format (full as clean markdown), and the method (by handle). This distinguishes it from sibling tools like 'search' or 'search_talent' which are for listing or 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 have a handle to retrieve a full profile, but it does not explicitly state when not to use it or provide alternatives. Sibling tools like 'fetch' or 'get_open_to_work' are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_searchAInspect
Save a talent search to your d.cv account so you can re-run it later. Requires your d.cv API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A name for the saved search | |
| query | Yes | The search text to save | |
| open_to_work | No | Whether the search is limited to open-to-work |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool requires an API key and is a write operation (save). However, with no annotations provided, it fails to clarify behavioral specifics such as whether saving overwrites an existing search with the same name, what the response format is, or error conditions like invalid keys.
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 extremely concise with two sentences. The first sentence front-loads the action and purpose, and the second sentence provides a critical prerequisite. No unnecessary words are present.
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 has 3 parameters, no output schema, and no annotations, the description lacks important details such as what the tool returns (e.g., success confirmation, saved search ID), how to handle potential errors, and idempotency behavior. This makes it incomplete for an AI agent to use reliably.
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?
All three parameters have schema descriptions covering 100% of properties. The tool description adds no additional meaning beyond what the schema already provides, meriting the baseline score of 3.
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 saves a talent search to the user's d.cv account for later re-running. It uses a specific verb ('save') and resource ('talent search'), and distinguishes itself from siblings like 'search' or 'search_talent' which are for executing searches, not saving them.
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 the user wants to persist a search query for later execution, and notes the prerequisite of needing a d.cv API key. However, it does not explicitly state when not to use it or mention alternative tools like 'search' for immediate results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Search d.cv talent profiles by free-text query (name, role, skills, location). Returns lightweight results with an id, title, and url. Use fetch to read one in full. (Standard connector search tool.)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, e.g. "senior react engineer in berlin" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output shape (lightweight results with id, title, url) and input type (free-text), but no annotations are provided. The description does not cover pagination, rate limits, or behavior with no results, leaving gaps.
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 short, front-loaded sentences with no redundancy. Every sentence adds value: what it does, what it returns, and guidance to use fetch for full details.
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 (one required param, no output schema, no annotations), the description covers purpose, output, and a usage hint. However, it could mention search scope limitations or error scenarios for 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?
Adds context beyond the schema: specifies fields searched (name, role, skills, location). Schema already covers the parameter with a good example, but the description enriches meaning.
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?
Clearly states the tool searches d.cv talent profiles by free-text query, specifies the resource (talent profiles) and action (search), and distinguishes from fetch by describing lightweight results.
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 use fetch for full profile reads, providing a clear alternative. However, it lacks explicit when-not guidance for sibling tools like search_talent, and the phrase 'Standard connector search tool' is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_talentAInspect
Find published candidate profiles on d.cv by keyword, skill, role, location, and availability. Returns structured candidates with handle, url, headline, skills, and open-to-work status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 25) | |
| query | No | Keywords across name, headline, location, and skills | |
| skills | No | Alias of query; specific skills to match | |
| open_to_work | No | If true, only return candidates open to work |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions that results are structured and lists fields, but lacks details on pagination, data freshness, authentication requirements, or potential side effects. More context is needed.
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, efficient sentence that front-loads the action and covers the key aspects. No unnecessary 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?
With no output schema, the description does specify return fields (handle, url, headline, skills, open-to-work status), which is helpful. However, it omits details like error handling, empty result behavior, and performance considerations, leaving some 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?
Schema description coverage is 100%, so the description adds marginal value beyond the schema. It confirms that the 'open_to_work' parameter filters by status, but the schema already conveys this. Baseline score of 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?
The description clearly states the tool's function: finding published candidate profiles on d.cv by various criteria. It specifies the resource ('candidate profiles') and the action ('find'), and the declaration of returned fields distinguishes it from sibling tools like 'search'.
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 through parameter descriptions (e.g., 'open_to_work') but does not explicitly state when to use this tool versus alternatives like 'search' or 'get_profile'. No guidance on when not to use it is provided.
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!