AI Interview Agents MCP Server

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Tools have distinct purposes with detailed descriptions, but there is slight overlap between schedule_interview and schedule_screened_candidates (both schedule interviews, one for unscreened and one for screened candidates). Overall, the differences are clear from the descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_meetings, create_screening_role, run_screening). No mixing of conventions like camelCase or irregular verbs.
Tool Count5/5
With 18 tools, the set covers the full interview management lifecycle without being overwhelming. Each tool serves a specific function, and the count is appropriate for the domain.
Completeness4/5
The tool surface covers the screening pipeline (from role creation to scheduling screened candidates) and interview management (schedule, cancel, reschedule, list, get details, report, reminders). Minor gaps include no tool for updating candidate email or deleting roles, but core workflows are well-supported.
Average 4.5/5 across 18 of 18 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on July 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is safe. The description adds that it returns status=processing if the report hasn't generated yet, which is important behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence conveys the purpose and contents, second sentence adds a special case. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers the core output fields and an edge case (processing). It lacks details on error states or prerequisites, but given the readOnly annotation, it is reasonably 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 should compensate. It does not explain the meeting_id parameter (e.g., what it refers to, format, or where to get it). The context implies it's an interview meeting ID, but explicitly documenting it would be helpful.
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 retrieves a scored interview report and lists specific fields (analysisSummary, strengths, etc.). It distinguishes from sibling tools like get_meeting, which likely returns raw meeting data, not a scored report.
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 like get_meeting or get_screening_results. There is no mention of prerequisites or context for when this report is available.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds the pipeline stages but does not disclose behavior like response format, pagination, or error handling. For a read-only tool, this is acceptable but not excellent.
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 short, focused sentences that front-load the core information. No unnecessary words or repetition. Efficiently conveys the essence.
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?
No output schema exists, so the description should hint at what is returned. It mentions stages but not whether it returns counts, candidate details, or both. For a simple tool, it is adequate but leaves some ambiguity.
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?
Single parameter role_id is self-explanatory from its name and type (integer). Schema coverage is 0%, but the description does not need to elaborate further. Baseline 3 is appropriate.
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 it's a pipeline view for a role with specific stages (invited, scheduled, completed, no-show). It directly answers the question 'how is the hiring going for this role', making the tool's purpose unambiguous.
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?
Explicitly says to use it to answer a specific question, providing clear context. However, it does not mention when not to use it or compare with sibling tools like get_screening_results, which could be similar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying the output includes 'transcript and feedback', which is beyond what annotations provide. However, it does not disclose potential errors or latency.
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 concise sentences with no fluff. The first sentence covers purpose and output content, the second clarifies the parameter. Every word is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains the return value (transcript and feedback) for a read-only tool with one parameter. It could be more detailed on the return structure, but overall it's sufficient for agent usage.
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 compensates by clarifying that 'meeting_id' accepts 'UUID or integer primary key', adding format details beyond the schema's string type. This helps agents correctly format the parameter.
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 verb 'get' and the resource 'single meeting', specifying it returns 'full details including transcript and feedback'. This differentiates it from sibling tools like 'list_meetings' which only list meetings without detailed content.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as needing a meeting ID from 'list_meetings', or exclude scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true. Description reinforces 'Read-only' and adds 'does not create a role or schedule anything,' which aligns with annotations and clarifies non-destructive nature. No additional behavioral traits disclosed beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences. First sentence states purpose, second clarifies scope, third hints at parameter values. No fluff, but could be better structured with bullet points for parameters.
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 8 parameters, no output schema, and many siblings, the description covers main use case and parameter hints. However, it lacks description of return format or behavior on invalid input, which is needed since no output schema exists.
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 provides enum values for interview_type and language, but leaves 6 other parameters (duration, position, company_name, job_description, required_skills, required_experience) unexplained. Insufficient for an 8-parameter tool.
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?
Clearly states action ('Generate interview questions using AI') and resource. Distinguishes from siblings by noting it does not create a role or schedule anything, and specifically references schedule_interview as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use to preview what the bot will ask before committing to schedule_interview.' Implies not to use for actual scheduling, providing clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive. Description adds that it emails the candidate and warns about awkward cleanup of wrong meetings. No contradictions; adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a brief warning block. No redundant information, front-loaded with purpose and outcome.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, guidelines, side effects (email), and caution about ambiguity. Does not mention constraints like meeting must be in future, but sufficient for most use cases given simplicity.
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?
One required parameter 'meeting_id' with 0% schema coverage. The description implies its use but does not explicitly explain its format or source. Adequate for a single-param tool, but could be more explicit.
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 verb 'Reschedule' and resource 'meeting', and specifies the outcome 'Emails the candidate a new invite link'. It differentiates from sibling 'cancel_interview' by referencing the same rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to ask before calling if the meeting is not unambiguously identified, and references sibling 'cancel_interview' for the same reasoning. Provides clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false and destructiveHint=false, but the description adds important behavioral details: 'Existing meetings cascade to the new role' and 'Records the reassignment in reassignmentAuditLogs with the optional reason.' It also warns about affecting open meetings. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, front-loaded with the core purpose. Every sentence adds value (side effects, audit logging, usage warnings). It is slightly verbose but not wasteful; could be more streamlined but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers key aspects: what it does, side effects (meetings cascade), recording in audit logs, and when to ask for confirmation. It lacks details on return value or potential errors, but overall it provides sufficient context for safe usage.
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 coverage is 0%, so the description must compensate. It names all three parameters (candidate_id, to_role_id, reason) and explains that reason is optional. However, it does not provide further detail like data types or expected values beyond what the schema shows. This adds moderate value but leaves gaps.
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 from their current role to a different one.' It specifies the verb (move/reassign) and resource (candidate), and the mention of existing meetings and audit logs adds specificity. Among siblings, no other tool performs reassignment, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'ASK BEFORE CALLING if either candidate_id or to_role_id is not unambiguous from the user's message.' It also instructs to confirm before moving because 'Reassignment affects all the candidate's open meetings.' This tells the agent when to call and when to avoid automated invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and not destructive. The description adds significant behavioral details: email is not required, CVs without email get a placeholder and are counted in withoutEmail, and they cannot be scheduled later until email is added. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but front-loaded with the main purpose. Every sentence adds value, though slightly verbose. Could be trimmed slightly but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return fields (savedCount, skippedEmpty, withoutEmail, candidates) and provides next-step guidance (call run_screening). This is complete for the tool's complexity.
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?
Schema coverage is 0%, but the description compensates by explaining the candidates parameter accepts two formats (rows from parse_cvs or flat dicts) and details the structure. role_id is not explained, but the main complex parameter is well described.
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 attaches parsed CVs to a screening as candidates. It specifies the input format (rows from parse_cvs or flat dicts) and distinguishes itself from sibling tools like schedule_screened_candidates by implying it's the step before run_screening.
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 tells when to use (after parse_cvs) and provides clear context about email handling and the next step (call run_screening). It does not explicitly state when not to use or mention alternatives, but the usage is well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only, non-destructive, non-open-world. Description adds that it creates a role record, returns roleId, does not auto-reject, and that location is a soft signal for remote roles. No contradictions.
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?
Well-structured with numbered flow, fields list, and usage notes. Front-loaded with return value. Slightly long but justified by complexity of 10 parameters and flow context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides return format (roleId), full flow, parameter details, and duplicate avoidance guidance. Lacks output schema but description compensates adequately for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description explains each of the 10 parameters with examples, constraints (e.g., required name, soft signals, language enum), and behavioral impact (e.g., job_description drives scoring).
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 creates a screening role, part of a CV ranking flow, and distinguishes it from sibling tools by explaining the overall flow and when to use list_screening_roles instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (creating a new screening), when not to (reuse existing roleId from list_screening_roles if duplicate), and outlines the complete six-step flow with tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations destructiveHint=true warn of side effects, but description adds crucial context: sends real emails, consumes quota, cannot undo, returns partial successes. Explains duration default (900 sec), self-served interview (no clock time), and response format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear warning section and logical flow. Somewhat long but each sentence adds value. No redundancy. Minor deduction for length could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return shape, partial success/failure, error conditions (400 for missing email), and preconditions. Covers side effects, quota consumption, and usage pattern. Highly complete for a destructive batch 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 has no descriptions (0% coverage). Description adds context: candidate_ids must come from get_screening_results with hasEmail=true, duration default 900. However, role_id is not explained, and other parameter nuances are missing. Partially compensates but not exhaustive.
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 it schedules AI interviews for screened candidates, sending real emails and consuming quota. It distinguishes from siblings like schedule_interview (individual) and add_screening_candidates by specifying the screening context and batch scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'CONFIRM BEFORE CALLING' with steps: read back candidates, get go-ahead, pull IDs from get_screening_results with hasEmail=true. Warns about placeholder emails causing 400 and mentions the tool uses stored config like the web action. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, destructiveHint=false), the description explains async scoring behavior, done-signals, result capping at limit, and truncation of 'reason' fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections, but slightly verbose. Every sentence adds value, though some details (e.g., full candidate fields) could be condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description provides a detailed output structure. It covers async behavior, status checks, and usage context. Missing explicit mention of requiring a prior screening run, but generally complete for a read tool.
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 description coverage, the description adds meaning for 'limit' (capping and default) and implicitly clarifies 'role_id' through context. It could explicitly state that 'role_id' identifies the screening's role.
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 'Read a screening's ranked candidates' with a specific verb ('read') and resource ('screening's ranked candidates'). It distinguishes from siblings like 'run_screening' and 'schedule_screened_candidates' by focusing on reading results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: after running a screening, how to check completion via screeningStatus, and when to poll again. It also names an alternative ('list_screening_roles') for checking candidate counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, destructiveHint=false), the description discloses that returns are paginated with totals for completed and cancelled, and that rows are summaries with transcripts/reports stripped to keep responses small. This adds meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for filters, but slightly verbose in parts (e.g., parenthetical 'compute the cutoff client-side'). However, every sentence adds value, and it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return type (paginated records, totals, role_name field), partial nature of data, and references sibling tools for full detail. This is complete for a list tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains each parameter: role_id, candidate_id, status (with enumerated values), and scheduled_after (with ISO datetime format and usage examples). This compensates entirely for the lack of schema 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 clearly states 'List interviews for the authenticated HR user.' It uses a specific verb and resource, and distinguishes itself from sibling tools like get_meeting and get_report by noting that rows are summaries and full detail is elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use filters (e.g., 'Use for last week / this month queries') and advises using get_meeting/get_report for full details. It also explains the role_name field as an easy way to surface recent roles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but description adds context about completion condition and meaning of fields beyond safety. No contradictions.
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?
Concise, front-loaded with purpose, followed by actionable details in a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers all aspects: what it does, what fields are returned, how to interpret them, and how it ties to run_screening. No gaps.
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?
No parameters exist; baseline 4 as description adds no confusion. Schema coverage 100% trivial.
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?
Clear verb 'list' with specific resource 'screenings (CV-screening roles)', distinguishes from siblings by mentioning roleId and avoiding duplicates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (find roleId to avoid duplicate, report progress) and provides signal for completion: 'screenedCount == candidateCount means scoring has finished'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive read but description adds context: OCR fallback, dedup logic, rejection of over 20 files. No contradictions.
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?
Well-structured with purpose first then details. Slightly wordy but each sentence adds value. Could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions returning candidate rows ready for schedule_interview. Could specify structure more precisely. Covers error handling and batch guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains the 'files' array requires name and bytes_base64 fields, and role_id for dedup. Schema is minimal but description compensates.
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 extracts candidate identity from CV/resume files, handles PDF/DOCX, and includes OCR fallback. It distinguishes from siblings like schedule_interview, add_screening_candidates, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: after parsing, show results before scheduling, then call schedule_interview. Also advises batching if more than 20 files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description discloses that meeting and candidate rows are deleted and that cancellation cannot be undone in-band. This adds critical context about side effects and recovery limitations.
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?
Efficiently structured with a clear purpose first, then destructive warning, and finally usage guidelines in a logical order. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with a single parameter and no output schema, the description covers purpose, behavior prerequisites, parameter source, and risks. No gaps remain for effective agent usage.
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?
Schema has 0% description coverage, but the description explains meeting_id as a value from list_meetings and implies its role in identifying the specific interview. While it doesn't specify format, the context is sufficient for a simple string parameter.
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 ('Cancel a scheduled interview') and identifies the resource (interview) with specific destructive consequences. It implicitly distinguishes from siblings like reschedule_interview by calling out its destructive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to ask before calling (ambiguous references) and directs to call list_meetings first. Also warns about irreversibility, offering a clear decision framework for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by detailing the return format with sample fields (roleId, name, position, etc.) and noting that recent ones should be surfaced, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet informative: first sentence defines purpose, then usage guidelines, then return format. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and annotations covering safety, the description covers purpose, usage, and return format. It provides enough context for the agent to use the tool correctly without gaps.
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?
The input schema has zero parameters, so the description does not need to add parameter information. Baseline for 0 params is 4; the description correctly omits param details.
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 'List the authenticated HR user's roles' which is a specific verb and resource. It clearly distinguishes from sibling tools like list_meetings or list_screening_roles by specifying roles as job postings/openings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this whenever the user hasn't named a role and you need to ask which role should I schedule against?' and gives example queries like 'what roles do I have'. This helps the agent select the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: async return, background scoring, idempotency with skip, force re-scoring, limit parameter, cheap model, safe for large roster. No contradictions.
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?
Well-formatted with async warning upfront, bullet points for details, no redundant sentences. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers async return, polling pattern, idempotency, force, limit, model safety. With no output schema, explains what to expect and how to get results.
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?
Despite 0% schema description coverage, explains all three parameters: force (re-score all), limit (cap candidates), role_id implied as required. Adds practical usage details.
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?
Clear action verb 'Start' with specific resource 'CV-vs-JD scoring for a screening's candidates'. Distinguishes from sibling tools like get_screening_results which reads results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states async behavior, polling pattern with get_screening_results, idempotency with force option, and when to expect scores. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description fully discloses write behavior (creates meetings, sends emails), dry run semantics (no persistence, no email, no quota), partial failure possibilities, and quota consumption. No contradiction with annotations (readOnlyHint=false, destructiveHint=false); adds context beyond annotation hints.
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?
Well-structured with clear section headers (ALL CAPS) and front-loaded critical rules. However, the description is lengthy and includes minor details (e.g., phone normalization to 10 digits Indian format) that could be delegated to the schema or a separate format specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters (2 required), no output schema, and nested objects, the description is exceptionally complete. Covers all parameters, error cases (partial failure, role_required response), dry run procedure, evaluation focus defaults, candidate field constraints, and timing nuances. Leaves no major gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description thoroughly explains all 13 parameters: dry_run, role_id, interview_type, duration, language, candidates (required fields, optional), evaluation_focus (default behavior), and others. Includes defaults, constraints (e.g., email well-formed), and interaction logic.
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 opens with 'Schedule AI-driven interviews. Creates meetings and sends invite emails,' clearly stating the verb and resource. It distinguishes from siblings like schedule_screened_candidates (which targets already-screened candidates) and reschedule_interview, eliminating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive guidance: explicit 'ASK BEFORE CALLING' for role selection, mandatory dry run when auto-filling, and explanation of when to skip dry run. It also clarifies when to use this tool versus asking the user for more info, and details the role_required error response pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation idempotentHint=true is reinforced with idempotency_key explanation; describes skipping completed meetings and batch limit. No contradictions.
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?
Well-structured with clear warnings, no redundant sentences, and efficient use of whitespace.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key behaviors, retry pattern, and batching; no output schema needed for this tool.
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?
Schema coverage is 0%, but description adds context for idempotency_key and meeting_ids cap. Lacks explicit mention of array type but adds useful semantics beyond 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 clearly states it sends reminder emails for pending interviews, distinguishing it from sibling tools like list_meetings or schedule_interview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: ask before calling for ambiguous requests, list meetings first, confirm with user, and mentions batch cap of 100.
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

Copy to your README.md:

[![aiia-mcp-server MCP server](https://glama.ai/mcp/servers/dpkdhingra91/aiia-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/dpkdhingra91/aiia-mcp-server)

Score Badge

Copy to your README.md:

[![aiia-mcp-server MCP server](https://glama.ai/mcp/servers/dpkdhingra91/aiia-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/dpkdhingra91/aiia-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/dpkdhingra91/aiia-mcp-server'

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