zoho-recruit

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but update_candidate_status and move_candidate_in_pipeline overlap in moving candidates through stages, though the latter is job-specific. Some tools like get_job_pipeline and hiring_funnel_report relate to pipelines but are clarified by descriptions.
Naming Consistency4/5
Tools predominantly follow verb_noun pattern (create, get, search, update, schedule, send, submit, move). A few use noun_noun (interview_summary_generator, source_analysis) but remain descriptive. Overall consistent and predictable.
Tool Count5/5
20 tools cover candidate management, job openings, interviews, email, and reporting without feeling excessive. Each tool serves a clear purpose within the recruiting domain.
Completeness4/5
Core recruiting lifecycle is well-covered: create/update/search candidates and jobs, schedule/submit feedback, reports. Missing delete operations (candidates, jobs) and explicit offer management, but these are minor gaps.
Average 3.1/5 across 20 of 20 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'Create', implying a write operation, but omits details like required permissions, idempotency, or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, achieving conciseness. However, it is too brief and omits necessary details, crossing into under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (1 required) and an output schema not referenced, the description is incomplete. It does not mention return values or the effect of optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 8 parameters (e.g., skills, location, department). With 0% schema description coverage, the description should compensate but fails to add any meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('a new job opening in Zoho Recruit'). It is specific and distinct from other tools like 'update_job_status', though it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as 'search_jobs' or 'update_job_status'. The description lacks contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic function, omitting details such as whether duplicate emails are handled, whether the candidate is automatically added to a pipeline, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks structure and fails to convey necessary details, making it insufficient for effective tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 2 required, output schema, 19 siblings), the description is grossly incomplete. It does not cover required fields, optional parameters, output, or integration with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about parameters. It does not explain the meaning, constraints, or usage of any of the 8 parameters (e.g., email, resume_url, experience_years).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (create), the resource (new candidate profile), and the system (Zoho Recruit). This distinguishes it from sibling tools like search_candidates or get_candidate_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., bulk_candidate_update, candidate_match_score). There is no mention of prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as authentication requirements, read-only nature, or pagination. The term 'list' implies read-only, but further details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 8 words, with no wasted text. However, it lacks structure or front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and presence of an output schema, the description is minimally adequate. However, it does not mention constraints (e.g., only 'currently associated' candidates) or typical use cases relative to the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'job_id' has no description in the schema (0% coverage) and the tool description does not clarify its format or purpose beyond the property name. This adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists candidates for a job opening, which distinguishes it from sibling tools like 'search_candidates' (general search) and 'get_candidate_details' (single candidate). However, it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says it generates structured feedback, but does not disclose behavioral traits like idempotency, authentication needs, or processing limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Turn'. It is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and an existing output schema, the description is minimally adequate. However, it does not mention expected transcript format or how the output relates to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'transcript' has no description in the schema (0% coverage). The tool description implies it is an interview transcript but adds no format or length details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Turn' and resource 'interview transcript', and lists output components. However, it does not differentiate from sibling tool 'submit_interview_feedback', which may be related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., 'submit_interview_feedback'). No when/when-not instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only specifies date/time formats but omits critical behavioral traits like whether it sends notifications, checks for conflicts, or requires specific permissions. This is insufficient for an API that likely performs side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded action verb. Every word serves a purpose. No unnecessary repetition or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters (4 required), no annotations, and an output schema. The description only addresses 2 parameters' formats and ignores the rest. It does not explain the overall effect (e.g., creates a calendar event, updates system). Given the complexity, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the format for 'date' and 'time', leaving 'candidate_id', 'interviewer', 'meeting_link', 'interview_name', and 'duration_minutes' unexplained. While date/time format is helpful, most parameters lack semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Schedule an interview' clearly states the action and resource. It distinguishes itself from sibling tools like get_interview_schedule (read-only) and submit_interview_feedback (post-interview action), though not explicitly. The verb+resource combination is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states what it does without context on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose whether the tool is read-only, requires permissions, or has any side effects. The behavioral characteristics are left entirely implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose. However, it omits important details, but the brevity is appropriate given the tool's straightforward nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not reference the return structure. With 5 parameters and multiple sibling report tools, the description lacks sufficient context to fully understand the tool's scope and relationship to others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should compensate by explaining each parameter's role. It only specifies the date format (YYYY-MM-DD) but does not clarify what role, recruiter, department, or the date range parameters do as filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a hiring funnel including specific stages (applicants, screening, interview, offers, joiners, rejections) and conversion percentages, which distinguishes it from siblings like recruiter_performance_report or get_job_pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as recruiter_performance_report or get_job_pipeline. It does not mention exclusions, prerequisites, or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details. It fails to mention pagination behavior (though page and per_page parameters exist), sorting, or whether the search is exact or fuzzy. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, with no redundant information. It is front-loaded with the purpose and efficiently lists filters, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 optional parameters and no annotations, the description is incomplete. It does not explain pagination or default behaviors, which are critical for a search tool. The presence of an output schema does not compensate for missing parameter explanations and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the keyword, skills (comma-separated), location, experience, status, and job_id filters, and provides an example. However, it does not explain page, per_page, or the specific formats for keyword, location, or status, leaving some parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches candidates and lists applicable filters. It distinguishes from sibling tools like get_candidate_details (which retrieves a single candidate) and search_jobs. However, it could be more explicit about the scope, e.g., returning a list of matching candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as get_candidate_details for a specific candidate. It also lacks prerequisites or context for appropriate use, which is essential for an agent to choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states what the tool does (analyze sources, counts, join rates) without mentioning side effects, permissions, data freshness, or pagination. This is insufficient for a production tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core functionality without extraneous words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (output schema exists, parameters optional), the description provides basic understanding but lacks detail on return values and parameter effects. It is adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter semantics. It does not mention the two parameters (date_from, date_to) or their role in filtering results. The phrase 'per-source counts and join rates' implies date-range filtering but does not clarify format, default behavior, or how null values are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: analyzing candidate sources with per-source counts and join rates. It mentions specific sources (LinkedIn, Naukri, Referral, Careers page), which adds specificity. However, it does not explicitly differentiate from sibling tools like 'hiring_funnel_report' or 'recruiter_performance_report', which might also involve source analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives. There is no information about prerequisites, ideal use cases, or when not to use it. Sibling tools offer related functionality (e.g., hiring_funnel_report) but the description does not help the agent choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully disclose behavior. It states 'List' implying read-only, but does not confirm safety, auth requirements, or any side effects. The only extra info is the pending_feedback_only parameter effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded and the parameter hint is concise. The description is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (handling return values), the description is incomplete for a 4-parameter tool with zero parameter documentation. It covers only one parameter and lacks details on date range and interviewer filtering, which are typical filtering needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain all parameters. Only pending_feedback_only is explained (as a filter for awaiting feedback). No meaning is added for to_date, from_date, or interviewer, leaving three parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists upcoming interviews and pending evaluations, with a specific verb ('List') and a distinct resource. However, it does not differentiate from sibling tools like get_candidate_details or get_job_pipeline, which also deal with schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing upcoming interviews and pending feedback, but provides no guidance on when not to use or alternatives. No exclusion criteria or context for filtering are mentioned beyond the boolean parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states the output is structured JSON but does not explain error handling, input format validation, or the effect of the use_zoho_parser flag. The phrase 'Provide a base64-encoded PDF or raw text' is ambiguous about which parameter corresponds to which input and whether one or both must be supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, clearly front-loaded with the purpose. It contains no filler. However, the phrase 'Provide a base64-encoded PDF or raw text' could be more tightly integrated into parameter guidance, and the sentence structure is slightly awkward. Still, it is concise and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (none required), 0% schema coverage, and an output schema (not described), the description is insufficient. It does not specify that at least one of resume_text or resume_base64 should be provided, nor does it explain the meaning of use_zoho_parser. The return value is partially indicated ('structured JSON with skills, experience...') but no details about the output schema shape. This leaves an agent likely to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by indicating that input can be base64-encoded PDF or raw text, which correlates to the two string parameters. However, it does not clarify that resume_text and resume_base64 are alternatives, nor does it explain the use_zoho_parser boolean. The description adds some value but leaves key semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses a resume into structured JSON, listing the extracted fields (skills, experience, companies, education, projects). It uses a specific verb ('Parse') and resource ('resume'), and is distinct from all sibling tools which focus on candidate/job management rather than document parsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, nor any conditions or prerequisites. The description does not mention that the tool expects either resume_text or resume_base64, nor when to set use_zoho_parser to true. Given the sibling tools include candidate_match_score which might also process resumes, the lack of comparative guidance is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a state change ('move') but does not disclose any behavioral traits like side effects, permissions needed, idempotency, or result format. Without annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that covers the core purpose without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists (not shown), the description omits important context like error conditions, case sensitivity, and differentiation from similar tools. It is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'status' parameter by listing example stages, but the 'candidate_id' parameter is left unexplained. With 0% schema coverage, the description partially compensates but needs more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move a candidate to a new stage') and provides concrete examples of stages, making the tool's purpose understandable. However, it does not differentiate from the sibling 'move_candidate_in_pipeline', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its alternatives, such as 'move_candidate_in_pipeline'. The description lacks context on prerequisites or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only mentions moving a candidate, implying a state change, but lacks details on side effects (e.g., notifications, permission requirements, idempotency). For a mutation tool, more behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief—two sentences—and front-loads the key action. Could be slightly more concise by removing the example, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (3 required), no enums, and an output schema, the description is incomplete. It does not explain the output schema or return value, does not mention prerequisites (e.g., candidate must be in a valid pipeline stage), and leaves ambiguity about whether the status is a stage name or ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints that 'status' refers to a stage name (e.g., 'Technical Interview'), but does not explain valid values, format, or relationship to the pipeline. Other parameters (job_id, candidate_id, comments) have no additional meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move a candidate'), the resource ('candidate'), and the context ('within a specific job's pipeline'), with an example ('Move candidate to Technical Interview stage'). It effectively distinguishes from sibling tools like get_job_pipeline (read-only) and update_candidate_status (general status update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage example but does not explicitly state when to use this tool versus alternatives like update_candidate_status or when not to use it. The example implies a typical use case but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the action (send email) without disclosing behavioral traits such as side effects, authentication needs, error handling, or return value expectations. Lacks sufficient transparency for an action tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every sentence adds value. No redundant or irrelevant information. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with zero schema coverage, the description should provide comprehensive guidance. It covers template and message but omits subject and the output/return behavior. Although an output schema exists, the description does not reference it, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining that 'template' can be a predefined enum string or a Zoho template_id, and that 'message' is for ad-hoc body. However, the 'subject' parameter is not described, and the interaction between template and message is unclear, partially compensating but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Send an email to a candidate' with a specific verb and resource. Distinguishes from sibling tools like create_candidate or update_candidate_status, though no explicit differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains how to use the tool (template options, ad-hoc message) but does not specify when to use vs alternatives or any exclusions. Since no alternative email tool exists, the guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not contradict schema but only mentions return fields. Lacks info on side effects, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently states purpose and return value. No wasted words, but could benefit from structured separation of purpose vs. output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and description complements it by naming return fields. However, parameter documentation is weak, and the tool has no usage context. Adequate for simple tools but incomplete for a scoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level details. It does not explain how candidate_skills should be formatted or what candidate_summary is for, despite the schema providing minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scores a candidate against a job description and lists specific outputs (match_percentage, strengths, gaps, recommendation). This distinguishes it from siblings like resume_parser or search_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_candidate_details or source_analysis. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states it updates the status, but does not mention what happens with invalid statuses, required permissions, side effects, or rate limits. The description does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the action and resource. While it could benefit from additional detail, it is not verbose and communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required parameters) and the presence of an output schema, the description is minimally adequate. However, it lacks parameter details and usage context, which are needed especially with 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning beyond the schema. It lists example valid statuses ('Open, Hold, Closed') but does not specify whether these are exhaustive, nor does it explain the format of 'job_id'. The description provides limited value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the specific resource ('a job opening's status') with example statuses ('Open, Hold, Closed'). It easily distinguishes from sibling tools like 'create_job_opening' (create) and 'update_candidate_status' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to change a job's status but lacks explicit guidance on when to use this tool vs alternatives, prerequisites, or scenarios where it is not appropriate. Given the number of sibling tools, some indication would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description lists what the tool returns (contact info, experience, etc.), which is transparent about output. However, with no annotations provided, it lacks disclosure of side effects, rate limits, authentication needs, or data sensitivity. The description partially compensates for missing annotations by stating the return fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the primary action and resource. No extraneous words; every part provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so the description adequately covers expected return. However, it does not mention error cases, rate limits, or any special behaviors. Given no annotations, the description could be more complete but meets basic needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the candidate_id parameter beyond its name. The description implies the parameter is the candidate's ID, but offers no additional semantics like format, source, or relation to other tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a candidate's full profile and enumerates specific fields like contact info, experience, skills, current company, status, and interview history. It uses a specific verb 'Get' and resource 'candidate's full profile', distinguishing it from sibling tools like search_candidates which return lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., search_candidates). It does not mention prerequisites such as requiring a candidate_id or context like needing full detail vs summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and description provides minimal behavioral context beyond stating it returns metrics. Does not disclose whether it's read-only, real-time, or any side effects, which is inadequate for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Essential information front-loaded. Ideal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 optional params and an output schema, the description is adequate for a simple metrics report. However, it lacks context on how recruiters are identified or if the date range is inclusive, leaving minor gaps for nuanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It only adds 'date_to' and 'date_from' implied from parameter names, but no format, required state, or behavior. Fails to add value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns per-recruiter metrics for candidates sourced, interviews, offers, closures. This is specific and distinguishes it from sibling tools like hiring_funnel_report (aggregate) or source_analysis (channel-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for recruiter-level performance data, but does not explicitly state when to use vs. alternatives. No guidance on prerequisites or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals that the tool can create or update records based on `interview_id`, which is useful. However, it does not disclose side effects (e.g., overwriting behavior), error states, authentication needs, or what happens on success. The description lacks sufficient behavioral detail for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, each adding distinct value. It is front-loaded with the core action and uses backticks to highlight parameter names, improving readability. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's main action and key parameter behaviors, but for a tool with 6 parameters (5 required) and an output schema, it omits critical details like the rating scale, feedback format, and success response. The output schema exists but is not described, so agents may lack context on return values. Overall, it meets basic needs but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to two parameters: `recommendation` (typical values) and `interview_id` (use to update). The schema has 0% description coverage, so the description partly compensates. However, it does not explain `rating`, `feedback`, `interviewer`, or `candidate_id`. More parameter-specific guidance would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Submit interview feedback.' It also specifies the typical values for `recommendation` (Hire/No Hire/Hold), adding specificity. The tool name itself is unambiguous, and the sibling tools are distinct (e.g., schedule_interview, interview_summary_generator), so no confusion arises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context on when to use the tool: it can create or update feedback via the `interview_id` parameter. However, it does not explicitly compare to alternatives or state when not to use this tool. More guidance on prerequisites or differentiation from similar tools (e.g., interview_summary_generator) would improve this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits. It states the tool returns 'open positions, status, and the assigned recruiter', but does not mention pagination behavior (page, per_page) despite the schema including those parameters. This is a notable gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose, the other providing an alternative usage. Every word serves a purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema, the description is insufficient. It mentions what is returned (open positions, status, recruiter) but omits how to filter (keyword, location, etc.) and pagination details. Users would need extra documentation to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about individual parameters. The tool has 7 parameters (keyword, location, status, etc.) but the description only says 'Search job openings', leaving their meanings entirely inferred. This fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Search job openings', specifying the tool's primary function. It distinguishes itself from sibling tool get_job_pipeline by directing users to use that tool for candidate pipeline needs, preventing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users when to use an alternative (get_job_pipeline for candidate pipeline), providing clear context. However, it does not address other siblings like search_candidates or create_job_opening, leaving some usage ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose important traits such as atomicity, error handling, idempotency, or rate limits. For a mutation tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, no wasted words. Efficiently communicates purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists (unseen), so return values are covered. However, the input complexity (arbitrary fields) demands more detail on constraints or success behavior; the description is basic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description clarifies that each update object must include an 'id' and fields to change, and provides a JSON example. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update many candidates at once,' clearly differentiating from the singular 'update_candidate_status' sibling. It provides a verb and resource, plus an example format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers a concrete use case ('reject all candidates who failed assessment'), indicating when to use this tool for bulk operations. It lacks explicit when-not or alternatives but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

zoho-recruit MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![zoho-recruit MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/yogeshsraju-max/zoho-recruit-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/yogeshsraju-max/zoho-recruit-mcp-server)

Score Badge

Copy to your README.md:

[![zoho-recruit MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/yogeshsraju-max/zoho-recruit-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/yogeshsraju-max/zoho-recruit-mcp-server)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![zoho-recruit MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fyogeshsraju-max%2Fzoho-recruit-mcp-server%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/yogeshsraju-max/zoho-recruit-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yogeshsraju-max/zoho-recruit-mcp-server'

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