Ask Recruitee the recruiting-ops questions dashboards miss by connecting candidate search, opening offers, departments, locations, published roles, owner fields, custom fields, public applications, and talent-pool context. Find stale candidate pools, overdue stage work, hiring-manager and recruiter bottlenecks, department-level opening risk, public posting gaps, source patterns, and the owners behind blocked hiring work. No dashboard build. No SQL.
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.
Average 3/5 across 17 of 17 tools scored. Lowest: 2.1/5.
Tools are mostly distinct, but the generic api_request overlaps with all specific CRUD tools, and list_candidate_search is confusingly named and may overlap with list_candidates. Some ambiguity exists.
Most tools follow a verb_noun snake_case pattern (e.g., create_candidate, get_admin), but api_request deviates as noun_noun and list_candidate_search uses a non-standard noun phrase. Overall mostly consistent.
17 tools cover a reasonable scope for an ATS integration, including candidates, openings, admins, and supporting entities. The count feels appropriate and not overwhelming.
The surface covers core CRUD for candidates and openings, but lacks update/delete operations, notes management beyond listing, and stage management. The generic api_request tool can compensate, but the dedicated tool set has notable gaps.
api_requestAInspectUse any documented Recruitee Ops Control Plane endpoint through the buyer's saved connection details.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full URL or documented path. | |
| method | Yes | ||
| confirm | No | Set true to run a live (non-GET) change. Ignored for GET and when dry_run=true. | |
| dry_run | No | Preview the action without sending it. | |
| body_json | No | JSON request body for documented write operations. | |
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| headers_json | No | Additional request headers for endpoints that require vendor-specific headers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: the tool uses the buyer's saved connection details for authentication, and includes confirm and dry_run parameters to control execution. However, it does not mention rate limits, error handling, or response format, leaving some 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?
The description is a single short sentence that conveys the core purpose. While it is concise, it could be more structured (e.g., separate bullet points for key behaviors). Still, it is free of fluff 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 complexity (7 parameters, generic API client), the description adequately covers the necessary context: authentication via saved connection, safety mechanisms (confirm, dry_run), and the scope of endpoints. It does not explain return values (no output schema), but that is acceptable per instructions.
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 high (86%), but the description adds value by explaining that confirm is ignored for GET and dry_run, and that body_json/query_json/headers_json are for documented endpoints. This context goes beyond the parameter types and descriptions in 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 it can be used to call any documented Recruitee Ops Control Plane endpoint, which is a specific verb-resource combination. It effectively distinguishes from sibling tools that cover individual CRUD operations, making the tool's generic purpose 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 implies this tool is for endpoints without dedicated tools, but it does not explicitly say when to use it versus siblings or when not to use it. No exclusion criteria or alternative recommendations are provided, relying on the agent to infer from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_candidateCInspectCreate a manually added Recruitee candidate.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true to run this live change. Ignored when dry_run=true. | |
| dry_run | No | Preview the action without sending it. | |
| body_json | No | JSON request body for documented write operations. | |
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| headers_json | No | Additional request headers for endpoints that require vendor-specific headers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as required permissions, idempotency, side effects (e.g., triggers, notifications), or potential errors. The sole sentence only restates the tool's name essentially.
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 extraneous words. It efficiently conveys the core purpose, though it could benefit from additional context.
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 6 parameters, no output schema, and no annotations, the description is too brief. It does not explain how to use the parameters, the structure of the candidate object, success/error behavior, or any prerequisites.
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?
Input schema coverage is 100%, and each parameter has its own description. The tool description adds no additional meaning beyond the schema, so 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 action 'Create' and the resource 'manually added Recruitee candidate'. It distinguishes from sibling tools like get_candidate and list_candidates, which are read-only, and from api_request which is generic.
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 is provided on when to use this tool versus alternatives. The description does not mention when to prefer this over api_request or other creation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_opening_offerCInspectCreate a Recruitee offer, meaning a job or talent pool.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true to run this live change. Ignored when dry_run=true. | |
| dry_run | No | Preview the action without sending it. | |
| body_json | No | JSON request body for documented write operations. | |
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| headers_json | No | Additional request headers for endpoints that require vendor-specific headers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It only states 'create', implying a write operation, but does not disclose behavioral traits such as required permissions, side effects, or the meaning of confirm/dry_run parameters beyond what schema already provides.
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 clear sentence with no wasted words. Could benefit from a brief usage hint, but remains concise.
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 6 parameters including confirm/dry_run and generic JSON objects, the description lacks explanations of how to use these parameters effectively. No output schema exists, but description does not need to cover return values. Overall, incomplete for a complex generic write tool.
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 parameters are well-documented in the schema. The description adds no additional meaning for parameters, so 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 states 'Create a Recruitee offer' with clarification that offer means a job or talent pool. This clearly identifies the resource and action, distinguishing from siblings like create_candidate. However, it does not differentiate from the generic api_request sibling.
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 vs alternatives like api_request or create_candidate. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_adminAInspectGet one admin. Company admins (recruiters and hiring managers) for resolving owner IDs to people and ranking owner workload.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | admin ID. | |
| include | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly implies a read operation but does not disclose permissions, error behavior, or rate limits. It adds some context about the tool's purpose but little beyond that.
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 concise: two sentences with no unnecessary words. The first sentence is a clear verb-resource pairing, and the second adds context. No fluff.
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 5 parameters, no output schema, and no annotations, the description is too sparse. It explains the tool's purpose but doesn't cover how to use parameters like 'include', 'query_json', or 'detail_profile', nor what the response contains. For a tool with this complexity, more detail is needed.
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 80%, so the schema already explains most parameters. The description adds no information about parameters (e.g., 'id', 'include', 'detail_profile'), providing no additional 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 verb 'Get' and resource 'admin', and explains the purpose: 'resolving owner IDs to people and ranking owner workload.' This distinguishes from sibling tools like 'list_admins' by focusing on a single entity.
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 explicit context for use: resolving owner IDs to people and ranking workload. It implies when to use (single admin retrieval) versus alternatives like 'list_admins', though it doesn't explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_candidateAInspectGet one candidate. Candidates with placements and stage information. Use created_after for server-side created-date filtering; use candidate_search filters_json for last_activity_at or updated_at searches.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | candidate ID. | |
| include | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only implies a read operation. It does not disclose error handling, rate limits, authentication needs, or side effects, leaving significant gaps for an agent's decision-making.
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 that front-load the core purpose and immediately provide actionable filtering advice, with 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, the description partially explains return data (placements and stage info) but omits error conditions, pagination (if any), and other response details, making it adequate but not comprehensive.
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 80% schema coverage, the description adds concrete examples (created_after, filters_json) that clarify the vague query_json parameter, providing 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 explicitly states 'Get one candidate' and adds that it returns placements and stage information, clearly distinguishing it from list tools like list_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?
Provides actionable guidance on using 'created_after' and 'candidate_search filters_json' for date filtering, though it does not explicitly contrast with sibling tools for when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_control_plane_capabilitiesAInspectShow Recruitee Ops Control Plane question, reporting, and action coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Show' implying read-only, but lacks details on side effects, authentication, rate limits, or response characteristics. For a tool with no annotation coverage, this is insufficient.
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 sentence that is both concise and front-loaded. Every word is necessary, no redundancy.
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 parameters and no output schema, the description is adequate but incomplete. It does not describe the output format or structure, which is important for an agent to interpret results. Additional detail on what 'coverage' entails (e.g., a JSON object with counts) would improve 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?
The tool has zero parameters, so according to guidelines the baseline is 4. The description adds no parameter information because none exist.
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 shows coverage for questions, reporting, and actions in the Recruitee Ops Control Plane. The specific verb 'Show' and resource 'coverage' make the purpose unambiguous, and it distinguishes itself from sibling tools that deal with candidates, openings, etc.
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?
There is no guidance on when to use this tool versus alternatives. While sibling tools cover different domains, no explicit usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_opening_offerBInspectGet one opening_offer. Recruitee offers, meaning jobs or talent pools, for opening inventory and owner analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | opening_offer ID. | |
| include | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get one,' implying a read operation, but does not confirm idempotency, rate limits, or any side effects, leaving the agent uninformed about safety.
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 short with two sentences, avoiding excessive detail. However, the second sentence is somewhat ambiguous ('for opening inventory and owner analysis') and could be more precise.
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 five parameters, including nested objects and an enum, the description is too brief. It does not explain the use of 'include', 'query_json', or 'path_params', nor does it describe the return value or error cases, leaving significant 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?
The input schema already describes 80% of the parameters (including id, query_json, detail_profile). The description adds no extra meaning to parameters; thus it meets the baseline but does not enhance understanding.
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 a single opening_offer and clarifies that these are jobs or talent pools. However, it does not mention the required 'id' parameter explicitly, which is essential for specifying which offer to fetch.
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 phrase 'Get one' implies a contrast with list operations like list_opening_offers, but there is no explicit guidance on when to use this tool versus siblings, nor any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_adminsCInspectList admins. Company admins (recruiters and hiring managers) for resolving owner IDs to people and ranking owner workload.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Fails to disclose read-only nature, authentication needs, pagination behavior, or side effects. Only states it lists admins.
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, concise but first sentence is tautological ('List admins'). Second sentence adds some context but could be more structured.
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?
Tool has 9 parameters, no output schema, and complex features (nested objects). Description lacks return value info, pagination behavior, and parameter usage details, making it incomplete.
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 only 33% with 9 parameters. Description adds no explanation for parameters like page, sort, limit, or query_json. Only 'detail_profile' has schema description; description does not compensate.
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 states 'List admins' and clarifies it lists company admins (recruiters and hiring managers) with specific use cases. It distinguishes from sibling 'get_admin' but could be more precise.
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 explicit when or when-not to use. Implies use for resolving owner IDs and ranking workload, but lacks guidance on alternatives like 'get_admin' or 'list_candidates'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_audit_logCInspectList audit_log. Audit log entries with pagination, search, and filters_json support.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only lists features (pagination, search, filters_json) but does not disclose behavioral traits such as read-only, destructive side effects, rate limits, or required permissions.
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 fluff, but under-specified. Missing critical information that would warrant a higher score.
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?
High parameter count (9) and no output schema. Description omits return value structure, pagination behavior, and filter usage details. Inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 9 parameters with only 33% description coverage. Description mentions 'pagination, search, filters_json' but does not explain individual parameters like page, sort, limit, cursor, include, per_page, or path_params. Fails to compensate for low schema coverage.
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 states 'List audit_log' which is clear verb+resource, but lacks differentiation from sibling list tools like list_admins or list_candidates. The mention of pagination, search, and filters_json support is generic.
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 mention of prerequisites, limitations, or exclusions. Agent receives no contextual cues for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_candidatesAInspectList candidates. Candidates with placements and stage information. Use created_after for server-side created-date filtering; use candidate_search filters_json for last_activity_at or updated_at searches.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| created_after | No | Only include records created at or after this ISO 8601 timestamp. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions server-side filtering and that results include placements and stage information, but lacks details on pagination, sort, limits, or response structure. Some transparency, but incomplete.
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 three sentences with no redundant words. The first sentence is somewhat tautological but the second and third provide value. It is concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is insufficient. It covers only two filtering options and does not address pagination, sorting, output format, or the meaning of parameters like query_json or path_params. The agent would need to infer much from the tool's name or trial.
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 only 40%. The description adds meaning for created_after and hints at candidate_search filters_json, but the latter is not a parameter in the schema and the description does not explain how to use it within query_json. Other crucial parameters like page, sort, limit, cursor, and detail_profile are left unexplained.
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 states 'List candidates' and adds that results include placements and stage information, clarifying the output. It is clear but does not explicitly differentiate from sibling 'list_candidate_search', though the distinction is implied by the filtering guidance.
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 the agent when to use created_after for created-date filtering and suggests using candidate_search (a sibling tool) for last_activity_at or updated_at searches, effectively guiding when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_candidate_searchCInspectList candidate_search. Candidate search. Pass documented filters as a JSON string in query_json.filters_json, including created_at, updated_at, last_activity_at, jobs, stages, sources, tags, overdue_at, and disqualified filters where supported by Recruitee.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions passing filters as JSON string but does not disclose read-only behavior, pagination, rate limits, or any side effects. Minimal behavioral info.
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 short (2 sentences) but starts with a vague phrase 'List candidate_search'. It does include some useful filter details. Could be more concise and front-loaded with purpose.
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 9 parameters, nested objects, no output schema, and no annotations, the description is incomplete. It does not explain pagination, output format, or how to use 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 33%, but description only adds limited info about a subset of filters (e.g., created_at, updated_at). Most parameters (page, limit, sort, etc.) are not described, nor is the nested structure explained.
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 states 'List candidate_search' and mentions filters for candidates, but it's ambiguous whether 'candidate_search' is a search object or the result of a search. It does not clearly distinguish from sibling 'list_candidates' tool.
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 like list_candidates. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_departmentsCInspectList departments. Company departments for function-level opening analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'List departments' with no disclosure of read-only behavior, pagination, filtering, or response format. Important behavioral traits like whether it supports pagination (implied by schema) are not mentioned.
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 concise at two sentences, but it is too minimal. It front-loads the purpose but omits essential details, making it less effective. Every sentence earns its place but more content is needed.
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 9 parameters, nested objects, and no output schema, the description is severely lacking. It does not explain what the tool returns, how pagination works, or when to use it. The context is insufficient for correct invocation.
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 only 33% schema description coverage, the description adds no parameter-specific information. The schema itself describes some parameters (e.g., detail_profile), but the tool's description does not clarify the meaning of parameters like cursor, query_json, or path_params.
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 verb 'List' and the resource 'departments', and adds context about being used for 'function-level opening analysis'. While it distinguishes from siblings like list_candidates or list_locations, it could be more explicit about the specific scope.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites or exclusions, leaving the agent to infer usage from the tool's name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_locationsCInspectList locations. Company locations for region and office slicing.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'List locations'. It doesn't disclose whether the operation is read-only, what happens with pagination, or any side effects. The description is insufficient for behavioral understanding.
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 but at the expense of necessary detail. It is under-specified rather than concise, as every sentence should earn its place but here it provides minimal 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?
Given the complexity of 9 parameters and no output schema, the description is incomplete. It doesn't cover return format, pagination behavior, or how to use filters. The tool is not adequately described for an agent to use 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 only 33%, yet the description adds no parameter meaning beyond the schema. It doesn't explain generic parameters like page, limit, cursor, or the complex query_json. The detail_profile parameter is documented in schema but not in description, failing to compensate for low coverage.
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 states 'List locations' which is a clear verb+resource, but 'for region and office slicing' is vague and doesn't precisely define the tool's scope or differentiate it from other list tools. It's above tautology but lacks specificity.
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 is provided on when to use this tool versus alternatives like list_admins or list_candidates. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_notesBInspectList notes. Notes for one candidate. Provide path_params.candidate_id.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it lists notes for one candidate, but does not mention pagination, rate limits, authentication needs, or what happens if the candidate is not found. The schema hints at pagination (cursor, page) but the description omits this.
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, comprising two short sentences that convey the essential purpose. Every word contributes value, and there is no fluff.
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?
Despite having 9 parameters and no output schema, the description does not explain pagination, filtering, or the response format. For a list tool, this leaves significant gaps that could hinder agent 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?
The schema description coverage is low (33%), but the description adds specific context for the path_params object by instructing to provide candidate_id. This interprets one parameter, but other parameters like page, limit, and cursor receive no additional meaning beyond their names.
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 lists notes and specifies 'Notes for one candidate', which distinguishes it from sibling tools like list_candidates. It also instructs to provide path_params.candidate_id, making the resource explicit.
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 tells the user to provide path_params.candidate_id, giving a basic usage hint. However, it does not discuss when to use this tool versus alternatives (e.g., when not to use it) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_opening_offersCInspectList opening_offers. Recruitee offers, meaning jobs or talent pools, for opening inventory and owner analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| limit | No | ||
| cursor | No | ||
| include | No | ||
| per_page | No | ||
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| detail_profile | No | operational (default) returns a compact recruiting-ops projection with names, prose, and other personal fields omitted; pass full to include the raw API payload with those fields. | operational |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits like read-only nature, pagination behavior, permissions, or side effects. The phrase 'opening inventory and owner analysis' is unclear.
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 but confusing. The first sentence is redundant with the tool name. The second sentence is unclear and not front-loaded effectively. It wastes words without providing clarity.
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 9 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain return values, pagination, or how to use the many parameters, leaving the agent without critical 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?
Schema description coverage is low (33%). The description adds no parameter information. While some parameters have schema descriptions, many (page, sort, limit, cursor, include, per_page) do not, and the tool description fails to compensate.
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 states verb 'list' and resource 'opening_offers', but the explanation 'Recruitee offers, meaning jobs or talent pools, for opening inventory and owner analysis' is vague and does not clearly differentiate from sibling tools like list_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 is provided on when to use this tool versus alternatives. Sibling tools include list_candidates and get_opening_offer, but no context is given for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
move_candidates_to_stageBInspectMove one or more Recruitee candidates to a stage for an offer. Provide body_json with candidates, offer_id, and stage_id.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true to run this live change. Ignored when dry_run=true. | |
| dry_run | No | Preview the action without sending it. | |
| body_json | No | JSON request body for documented write operations. | |
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| headers_json | No | Additional request headers for endpoints that require vendor-specific headers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as idempotency, permission requirements, or side effects. The presence of confirm and dry_run parameters suggests caution, but this is not mentioned in the description.
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 states the purpose, the second provides a key usage hint. 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 the absence of annotations and output schema, the description fails to cover important aspects: return value, confirm/dry_run behavior, error handling, or any prerequisites. The tool has 6 parameters but only one is partially explained.
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%, but the description adds value by specifying that body_json should contain 'candidates, offer_id, and stage_id'. However, it does not detail the structure of these fields, leaving some ambiguity.
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 ('Move one or more Recruitee candidates to a stage for an offer'), with specific verb and resource. It distinguishes from sibling tools like create_candidate and create_opening_offer by focusing on stage movement.
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 usage guidance is provided; the description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. With numerous sibling tools, explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_candidate_custom_fieldsCInspectSet candidate custom fields.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true to run this live change. Ignored when dry_run=true. | |
| dry_run | No | Preview the action without sending it. | |
| body_json | No | JSON request body for documented write operations. | |
| query_json | No | Additional documented query parameters, including bracketed filter keys. | |
| path_params | No | Values for path placeholders such as {id} in a write operation. | |
| headers_json | No | Additional request headers for endpoints that require vendor-specific headers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only states 'Set candidate custom fields' without explaining effects (overwrite vs append), required permissions, or safety profile. The schema hints at a generic API request pattern, but the description adds no 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?
The description is extremely short (one sentence) but at the cost of critical information. It is under-specified rather than efficiently concise, failing to earn its place with substantive content.
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 complexity (6 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It does not explain what custom fields are, how to use body_json/path_params/query_json, or what the expected outcome is.
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 all 6 parameters. The tool description adds no additional meaning beyond the schema, meeting the baseline. However, it does not explain how to combine parameters or provide usage examples.
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 'Set candidate custom fields' is a verb+resource that distinguishes from sibling tools (none others mention custom fields), but it is essentially a tautology of the tool name. It does not specify whether it updates, replaces, or adds fields, leaving the exact purpose vague.
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 is provided on when to use this tool versus alternatives like create_candidate or move_candidates_to_stage. There are no usage contexts, prerequisites, or exclusions mentioned.
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.
No comments yet. Be the first to start the discussion!
