The AI HR Management Toolkit provides 21 MCP tools for AI-powered resume parsing, candidate analysis, and full Applicant Tracking System (ATS) management — primarily algorithmic, with no mandatory AI/API keys required.
Resume Parsing & Analysis
Parse PDF, DOCX, TXT, MD files or URLs into structured JSON (contacts, keywords, section maps)
Batch parse up to 20 resumes in a single call
Run a 5-stage pipeline (Ingestion → Sanitization → Tokenization → Classification → Serialization) with confidence scoring and data quality reports
Extract keywords (TF-IDF), detect patterns (dates, metrics, career trajectory), classify entities via NER (12 types), and extract structured skills (13 categories) with proficiency estimates
Extract structured work experience (titles, organizations, durations, achievements, technologies)
Compute resume-to-job-description similarity using cosine similarity, Jaccard index, TF-IDF overlap, and skill gap analysis
Run all of the above in a single analyze_resume call
Candidate Scoring & Assessment
Score candidates against up to 8 weighted criteria axes (Education, Experience, Skills, Certifications, etc.)
Generate pass/review/reject decisions algorithmically or via optional LLM-based assessment
Rank, filter, compare, and recommend stage changes for candidates
Full ATS Management
Jobs: Create, read, update, delete, list, search, close, and reopen job postings
Candidates & Pipeline: Add, update, delete, bulk-move candidates through stages (applied → screening → interview → offer → hired); view pipeline analytics with stage distribution, conversion rates, time-in-stage, and bottleneck detection
Interviews: Schedule with conflict detection; submit, retrieve, and analyze feedback with consensus scores and hiring signal summaries
Offers: Manage full lifecycle (draft → pending → approved → sent → accepted/declined/expired), plus comparison and validation
Notes: Add, update, list, search, and bulk-add timestamped candidate notes
Global Search: Full-text search across all ATS entities
Enterprise HR Features
EEO/EEOC compliance reporting, GDPR data export/erasure, audit trails, and data retention policies
Talent pools for passive candidate CRM
Structured interview scorecards with weighted criteria and aggregate rankings
Post-hire onboarding checklists with task assignment, progress tracking, and overdue alerts
Email templates with variable interpolation, send/preview, and communication history
Export, Communication & Integration
Export results to JSON or CSV
Send results via SMTP email (credentials passed per call, no server-side storage)
Works with MCP clients (Claude Desktop, Cursor, VS Code Copilot, Windsurf) and multiple AI providers (OpenAI, Anthropic, Google, DeepSeek, etc.)
Deployable via NPX, global install, remote HTTP endpoint, or local development
Includes a web UI with chat interface and ATS dashboard, plus REST API endpoints
Generate realistic demo data for testing and demonstrations
AI-powered resume parser & full Applicant Tracking System with 21 MCP tools. Parse PDFs, extract skills, detect patterns, score candidates, and manage a complete hiring pipeline — all from your AI assistant, no manual work required.
Live demo: https://ai-hr-management-toolkit.vercel.app
You have 50 resumes to screen. Your AI assistant can reason about candidates — but it cannot open PDFs, extract structured data, or track pipeline stages. This toolkit bridges that gap.
Give your AI assistant 21 tools covering the entire hiring workflow:
Parse PDFs, DOCX, TXT, Markdown, and URLs into structured JSON
Extract skills, experience, keywords, and entities algorithmically
Score and rank candidates against job descriptions
Run a full ATS: jobs, candidates, interviews, offers, notes, and analytics
20 of 21 tools are 100% algorithmic — no LLM calls, no API keys required. The AI calls tools, interprets the results, and delivers analysis. You just ask questions.
Related MCP server: Workopia
No installation needed. Point your MCP client at the package:
Claude Desktop — Edit %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"ai-hr-management-toolkit": {
"command": "npx",
"args": ["-y", "mcp-ai-hr-management-toolkit"]
}
}
}Example usage:
Cursor — Add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"ai-hr-management-toolkit": {
"command": "npx",
"args": ["-y", "mcp-ai-hr-management-toolkit"]
}
}
}VS Code Copilot — Create .vscode/mcp.json in your project root:
{
"servers": {
"ai-hr-management-toolkit": {
"command": "npx",
"args": ["-y", "mcp-ai-hr-management-toolkit"]
}
}
}VS Code users: Run the
npxcommand from a directory that contains apackage.json(i.e. any project root). Thecwdkey in.vscode/mcp.jsoncan override the working directory if needed.
Windsurf / other MCP clients — Use the same npx pattern above.
Works from any project directory (requires a package.json in the working directory):
{
"mcpServers": {
"ai-hr-management-toolkit": {
"command": "npx",
"args": ["-y", "mcp-ai-hr-management-toolkit"]
}
}
}Install once, use from any directory:
npm install -g mcp-ai-hr-management-toolkit{
"mcpServers": {
"ai-hr-management-toolkit": {
"command": "mcp-ai-hr-management-toolkit",
"args": []
}
}
}Deploy the Next.js app and use the Streamable HTTP transport:
https://your-domain.com/api/mcpTest locally:
npx @modelcontextprotocol/inspector http://localhost:3000/api/mcpgit clone <repo-url>
cd Resume-parser
npm install
npm run devWeb UI at http://localhost:3000. MCP endpoint at http://localhost:3000/api/mcp. No .env needed — configure API keys in the UI or pass them per tool call.
All tools return structured JSON with next_steps hints so the AI knows what to call next.
Tool | What it does | AI? |
| Parse PDF / DOCX / TXT / MD / URL → raw text + contacts, keywords, section map | No |
| Parse up to 20 files in one call, full pipeline on each | No |
| Run the 5-stage analysis pipeline → confidence scores, entity counts, data quality report | No |
Tool | What it does | AI? |
| Master analysis tool with selectable aspects: | No |
analyze_resumeconsolidates what were previously 7 separate tools (extract_keywords,detect_patterns,classify_entities,extract_skills_structured,extract_experience_structured,compute_similarity,analyze_resume_comprehensive) into a single entry point with aspect selection.
Tool | What it does | AI? |
| Score against up to 8 weighted criteria axes → weighted total + pass / review / reject decision | Optional |
Tool | What it does | AI? |
| Export structured parse results to JSON or CSV | No |
| Send results via SMTP (config passed per call — no server-side secrets stored) | No |
Tool | What it does | AI? |
| Full CRUD for job postings: create, read, update, delete, list, search by title/department/status | No |
Tool | What it does | AI? |
| CRUD + analytics: add, update, move stage, bulk-move, filter, rank, compare, recommend stage changes, summarize | No |
| Unified dashboard + pipeline analytics: stage distribution, conversion rates, avg time-in-stage, bottleneck detection, offer acceptance rate | No |
| Global full-text search across all ATS entities (candidates, jobs, interviews, offers, notes) | No |
Tool | What it does | AI? |
| Create, update, and delete interviews with conflict detection and interviewer availability check | No |
| Submit structured feedback, compute consensus score, summarize feedback across all interviewers | No |
Tool | What it does | AI? |
| Full offer lifecycle: draft → pending → approved → sent → accepted / declined / expired | No |
| Add, update, search, and delete timestamped candidate notes | No |
Tool | What it does | AI? |
| EEO/EEOC reporting, GDPR export/erasure, audit trail, data retention policies | No |
| Passive candidate talent pools (CRM): create pools, add/remove candidates, search, analytics | No |
| Structured interview scorecards with weighted criteria, per-evaluator scores, aggregate rankings | No |
| Post-hire onboarding checklists: tasks by category, assignees, progress tracking, overdue alerts | No |
| Email templates with | No |
Tool | What it does | AI? |
| Generate a realistic sample ATS dataset (jobs, candidates, interviews, offers) for testing | No |
assess_candidateoptionally calls an LLM when you supplyprovider+apiKey; it falls back to fully algorithmic scoring otherwise.
You: "Parse this resume and tell me if they're a good fit for our Senior Engineer role"
AI → parse_resume(file)
→ raw text, contact info, section map
AI → inspect_pipeline(rawText)
→ 5-stage confidence scores, entity classification
AI → analyze_resume(text, aspects=["skills", "patterns", "similarity"], jobDescription=...)
→ 13 skill categories with proficiency levels
→ career trajectory, metrics, date ranges
→ cosine 0.74, skill match 82%, gap analysis
AI synthesizes → "Strong match. 6 of 8 required skills present.
Two gaps: Kubernetes and system design at scale.
Recommend: Technical Screen"Every resume runs through a 5-stage algorithmic pipeline:
┌─────────────┐ ┌──────────────┐ ┌──────────────┐ ┌────────────────┐ ┌───────────────┐
│ Ingestion │───▶│ Sanitization │───▶│ Tokenization │───▶│ Classification │───▶│ Serialization │
│ (file/URL) │ │ (noise trim) │ │ (TF-IDF) │ │ (NER + disamb) │ │ (structured) │
└─────────────┘ └──────────────┘ └──────────────┘ └────────────────┘ └───────────────┘Ingestion — PDF via pdf-parse v2, DOCX via mammoth, HTML/URL via cheerio, plain text/markdown natively
Sanitization — Removes non-ASCII artifacts, normalizes whitespace, strips formatting noise
Tokenization — TF-IDF with unigrams, bigrams, and trigrams; scored by document frequency
Classification — NER with domain-aware disambiguation (e.g. "Java" as language vs. Indonesian city; "Go" as language vs. verb)
Serialization — Maps entities to typed ResumeSchema with confidence scores and data quality metrics
Format | Extensions | Parser |
| pdf-parse v2 | |
DOCX |
| mammoth |
Plain text |
| direct read |
Markdown |
| regex-based |
URL / HTML | any URL string | cheerio |
Max file size: 10 MB
contact — name, email, phone, location, LinkedIn, GitHub, website, portfolio
summary — professional summary text
skills[] — name, category (13 types), proficiency, usage context
experience[] — company, title, start/end dates, highlights, achievements (with metrics), technologies
education[] — institution, degree, field, dates, GPA
certifications[] — name, issuer, date, credential URL
projects[] — name, description, URL, technologies, highlights
languages[] — spoken language and proficiencyThe app ships with a full web interface:
Tab | Description |
Single Parse | Upload one file or paste a URL. Returns structured data, pipeline visualization, and AI-enhanced analysis |
Batch Parse | Upload up to 20 files. Export to JSON / CSV / PDF or email results |
Chat | Conversational interface with tool access — ask questions about any parsed resume |
ATS | Full pipeline board: jobs, candidates (Kanban), interviews, offers, and analytics dashboard |
Switch AI providers from the selector at the top. Supports OpenAI, Anthropic, Google, DeepSeek, GLM, Qwen, OpenRouter, and OpenCode Zen.
All endpoints accept multipart/form-data with optional headers:
Header | Description |
| Your AI provider API key |
|
|
| Specific model ID |
# Parse a single resume
curl -X POST http://localhost:3000/api/parse \
-H "x-api-key: sk-..." \
-F "file=@resume.pdf"
# Batch parse (up to 20 files)
curl -X POST http://localhost:3000/api/batch-parse \
-H "x-api-key: sk-..." \
-F "files=@resume1.pdf" \
-F "files=@resume2.docx"
# MCP endpoint (Streamable HTTP)
curl -X POST http://localhost:3000/api/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"tools/list","id":1}'
# Export parsed data
curl -X POST http://localhost:3000/api/export \
-H "Content-Type: application/json" \
-d '{"format":"csv","results":[...]}'Layer | Technologies |
Framework | Next.js 16 (App Router, Turbopack), React 19, TypeScript |
AI | Vercel AI SDK v6, multi-provider (OpenAI, Anthropic, Google, DeepSeek, GLM, Qwen, OpenRouter) |
MCP |
|
Parsing | pdf-parse v2, mammoth, cheerio |
NLP | TF-IDF, NER, cosine similarity, Jaccard index (all in-process, no external services) |
Schema | Zod v4 |
Export | ExcelJS (CSV/XLSX), jsPDF + jspdf-autotable |
Nodemailer | |
Styling | Tailwind CSS v4, Framer Motion |
npm install
# Start dev server (Web UI at :3000 + MCP at /api/mcp)
npm run dev
# Build the standalone MCP CLI (stdio transport)
npm run build:mcp
# Build the Next.js app for production
npm run build
# Test MCP with the official inspector
npx @modelcontextprotocol/inspector http://localhost:3000/api/mcp
npx @modelcontextprotocol/inspector node dist/mcp-stdio.js
# Lint
npm run lintsrc/
├── app/
│ ├── page.tsx # Main UI (tabs, provider selector, chat, ATS)
│ ├── layout.tsx # Root layout + global styles
│ └── api/
│ ├── parse/route.ts # Single resume parse
│ ├── batch-parse/route.ts
│ ├── chat/route.ts # Conversational AI with tool access
│ ├── mcp/route.ts # MCP server (Streamable HTTP)
│ ├── models/route.ts # Provider model listing
│ ├── export/route.ts # JSON / CSV / PDF export
│ └── email/route.ts # SMTP email
├── components/ # React UI components (parse, batch, chat, ATS)
│ └── ats/ # ATS-specific views (Kanban, Dashboard, Scheduler…)
└── lib/
├── ai-model.ts # Multi-provider model config (no env fallback)
├── mcp-server.ts # MCP server — registers all 21 tools
├── schemas/
│ ├── resume.ts # Zod v4 ResumeSchema
│ └── criteria.ts # Assessment criteria schema
├── analysis/
│ ├── pipeline.ts # 5-stage pipeline orchestrator
│ ├── sanitizer.ts # Text cleaning
│ ├── keyword-extractor.ts # TF-IDF
│ ├── classifier.ts # NER with context disambiguation
│ ├── pattern-matcher.ts # Regex extraction (metrics, dates, contacts)
│ └── scoring.ts # Cosine similarity, Jaccard, skill matching
├── parser/
│ ├── pdf.ts, docx.ts, text.ts, markdown.ts, url.ts
│ └── index.ts
├── ats/
│ ├── types.ts # ATS entity types
│ ├── store.ts # In-memory ATS state
│ ├── demo-data.ts # Realistic seed data generator
│ └── context.tsx # React context for ATS state
└── tools/
├── parse-resume.ts # parse_resume
├── inspect-pipeline.ts # inspect_pipeline
├── export-results.ts # export_results
├── send-email.ts # send_email
└── mcp/ # 17 MCP-specific tools
├── analyze-resume.ts # analyze_resume (unified: keywords, patterns, entities, skills, experience, similarity)
├── batch-parse.ts # batch_parse_resumes
├── assess-candidate.ts # assess_candidate
├── ats-manage-candidates.ts # ats_manage_candidates (includes rank/filter/compare/summarize)
├── ats-manage-jobs.ts
├── ats-manage-offers.ts
├── ats-manage-notes.ts
├── ats-analytics.ts # ats_analytics (unified dashboard + pipeline)
├── ats-schedule-interview.ts
├── ats-interview-feedback.ts
├── ats-search.ts
├── ats-generate-demo-data.ts
├── ats-compliance.ts # Enterprise: EEO / GDPR / audit
├── ats-talent-pool.ts # Enterprise: passive candidate CRM
├── ats-scorecard.ts # Enterprise: structured scorecards
├── ats-onboarding.ts # Enterprise: onboarding checklists
└── ats-communication.ts # Enterprise: email templates & historyRun a comprehensive algorithmic analysis on a resume in a single call. Accepts raw text or a file (base64-encoded PDF/DOCX/TXT/MD or URL). Runs the full 5-node pipeline (Ingestion → Sanitization → Tokenization → Classification → Serialization) and returns: pipeline confidence scores, classified entities by type, categorized skills with proficiency estimates, structured experience timeline, career analysis, contact info, metrics/achievements, section quality assessment, and data quality scores. Optionally matches against a job description. This is a one-call alternative to chaining parse_resume + inspect_pipeline + classify_entities + extract_skills_structured + extract_experience_structured + compute_similarity.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Base64-encoded file content or URL. Use with fileType. Ignored if resumeText is provided. | |
| fileType | No | File type when using content parameter | |
| resumeText | No | Raw resume text. Provide either resumeText OR (content + fileType), not both. | |
| jobDescription | No | Optional job description to compute similarity and skill gap analysis | |
| requiredSkills | No | Optional required skills to check against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by detailing the 5-node pipeline and what outputs are returned (confidence scores, entities, skills, timeline, etc.), without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive and well-structured but slightly verbose. It front-loads the purpose and then lists details, though some sentences could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 5 parameters, no output schema, and a pipeline, the description covers inputs, pipeline steps, outputs, and usage context (alternative to chaining). It leaves no critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning: explains each parameter (content, fileType, resumeText, jobDescription, requiredSkills) including the mutual exclusivity of content+fileType vs resumeText, and optional nature of job matching parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it runs comprehensive algorithmic analysis on a resume, lists pipeline stages and returns, and distinguishes from sibling tools by noting it's a one-call alternative to chaining multiple specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states this is a one-call alternative to chaining other tools, providing clear guidance on when to use it. Input options are explained (raw text or file with fileType). No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess a resume against recruiter-defined criteria. Supports 8 criteria axes: Education, Experience, Skills, Certifications, Knowledge Stack, Competitions, Thresholds, and Job Qualification. Returns per-axis scores, weighted overall score, and a pass/review/reject decision.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name | |
| apiKey | No | API key for the AI provider | |
| content | Yes | Base64-encoded file content, or URL string when fileType is 'url', or plain resume text when fileType is 'txt' | |
| criteria | Yes | Assessment criteria object. Structure: { name: string, education: { enabled, weight, minimumDegreeLevel, preferredFields, targetUniversities, acceptAnyAccredited }, experience: { enabled, weight, minimumYears, preferredYearsRange, requiredIndustries, preferredCompanies, requiredJobTitles }, skills: { enabled, weight, requiredSkills: [{name, required, minimumProficiency}], niceToHaveSkills, minimumSkillMatchPercent }, certifications: { enabled, weight, requiredCertifications, preferredCertifications }, knowledgeStack: { enabled, weight, requiredLanguages, requiredFrameworks, requiredTools, requiredDatabases, requiredPlatforms }, competitions: { enabled, weight, valuedCompetitions, requirePublications, requirePatents, requireOpenSource }, thresholds: { autoPassPercent, reviewRangePercent, autoRejectBelowPercent }, jobQualification: { enabled, weight, jobDescription, companyCultureKeywords, softSkillsRequired, leadershipRequired } } | |
| fileType | Yes | File type | |
| provider | No | AI provider (openai, anthropic, google, deepseek, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld. The description adds behavioral context: returns per-axis scores and decision, and supports multiple criteria axes. No contradictions, and it provides 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and output, no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested criteria and no output schema, the description adequately conveys purpose, inputs, and outputs. It could mention more about the criteria structure, but the schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with detailed parameter docs. The description reiterates the criteria axes but doesn't add new meaning beyond the schema. Baseline 3 is appropriate as schema covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses a resume against recruiter-defined criteria, lists 8 specific axes, and mentions outputs like per-axis scores and decision. It distinguishes from siblings like parse_resume or analyze_resume_comprehensive by focusing on structured criteria evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for custom criteria assessment, but no explicit guidance on when to use vs. alternatives (e.g., analyze_resume_comprehensive) or when not to use. The description lacks exclusion criteria or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate comprehensive ATS dashboard statistics and hiring health report. Provide the full ATS state (candidates, jobs, interviews, offers). Returns key metrics, pipeline health, hiring velocity, and actionable insights.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ATS state object with candidates, jobs, interviews, and offers records (each keyed by ID). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's addition of output details (metrics, pipeline health) provides some extra context but no behavioral surprises. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with the purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input and lack of output schema, the description explains the returned values (metrics, pipeline health, velocity, insights) adequately. Could be more specific but sufficient for an overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'state' parameter. The description repeats that it expects candidates, jobs, interviews, and offers, which adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates comprehensive ATS dashboard statistics and hiring health report, specifying it covers candidates, jobs, interviews, and offers. It implies a broad overview but does not explicitly differentiate from sibling tools like ats_pipeline_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It only describes the function without stating contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a full set of realistic demo data for the ATS (Applicant Tracking System). Returns a complete ATSState with sample jobs, candidates at various pipeline stages, scheduled interviews, and offers. Useful for testing, demonstrations, or populating an empty ATS instance.
| Name | Required | Description | Default |
|---|---|---|---|
| includeStats | No | If true, include summary statistics alongside the generated data. Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's not read-only and not destructive. The description adds that it returns a complete ATSState with sample data, but does not detail side effects or permissions. With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, second sentence adds usage context. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generative tool with no required parameters and no output schema, the description explains what it generates (jobs, candidates, interviews, offers) and its return type (ATSState). Could mention output format more, but sufficient for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter documented). The description does not mention the 'includeStats' parameter, but the schema description already covers it. Baseline 3 is appropriate as no extra meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a full set of realistic demo data for the ATS', specifying the verb, resource, and scope. It distinguishes from sibling tools like ats_manage_jobs which manage existing data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Useful for testing, demonstrations, or populating an empty ATS instance', providing clear context. No explicit exclusions or alternatives, but the purpose is well-defined enough to infer when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage interview feedback in the ATS. Actions: submit (add feedback to completed interview), get (retrieve feedback for an interview), update (modify existing feedback), list_pending (interviews awaiting feedback), list_completed (interviews with feedback, optionally filtered by candidate), analyze (aggregate feedback for a candidate across all interviews), summary (hiring signal summary for a job or all jobs).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. "type": "submit" | "get" | "update" | "list_pending" | "list_completed" | "analyze" | "summary". | |
| interviews | Yes | Current interviews record: Record<id, interviewObject>. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is a mutating operation but not destructive. The description adds no additional behavioral context beyond the listed actions, such as prerequisites, side effects, or constraints (e.g., that submit requires a completed interview).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise paragraph that front-loads the tool's purpose and lists actions without unnecessary words. Every sentence adds value, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with seven sub-operations and a nested input schema, the description provides only high-level action names. Since there is no output schema, the description does not explain return values or behavior, leaving the agent with incomplete information for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for the 'interviews' and 'action' parameters; it simply lists possible action types without elaborating on their structure or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage interview feedback in the ATS' and lists seven specific actions (submit, get, update, list_pending, list_completed, analyze, summary), providing a specific verb and resource. It distinguishes the tool from sibling tools which focus on resumes, candidates, jobs, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage contexts through the listed actions (e.g., list_pending for awaiting feedback), but it does not provide explicit guidance on when to use this tool versus alternatives or which action to select. No exclusions or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage candidates in the ATS pipeline. Supports add, update, delete, move between stages, bulk move, and list/filter operations. Pass the current candidates record and an action to perform. Returns the updated candidates and a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. Types: - { type: "add", candidate: { firstName, lastName, email, phone?, jobId, currentStage?, tags?, source? } } - { type: "update", candidateId: string, fields: { partial candidate fields } } - { type: "delete", candidateId: string } - { type: "move", move: { candidateId, newStage } } - { type: "bulk_move", moves: [{ candidateId, newStage }, ...] } - { type: "list", jobId?: string, stage?: string } | |
| candidates | Yes | Current candidates record (id → candidate object). Pass {} for a fresh start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true). The description adds that it returns updated candidates and a summary, but does not detail side effects, permission requirements, or rollback behavior. With annotations bearing the main safety signal, the description provides marginal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences, first enumerating supported operations and second explaining usage. No wasted words, but could be more structured with clearer separation of actions and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with multiple complex actions and nested parameters, the description covers the return value (updated candidates and summary) and the input pattern. It lacks error handling or idempotency notes, but given the rich schema and annotations, completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description reiterates that candidates should be the current record. The description adds a slight reminder, but does not provide additional meaning beyond the already detailed action schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages candidates in an ATS pipeline and lists specific operations (add, update, delete, move, bulk move, list/filter). This distinguishes it from generic candidate management tools like 'manage_candidates' but lacks explicit differentiation from 'ats_manage_jobs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage guidance ('Pass the current candidates record and an action to perform') but neither specifies when to use this tool over siblings nor offers exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage job postings in the ATS. Actions: create (new job posting), update (edit fields), delete, list (with optional status/department filter), search (by keyword in title/description), close, reopen. Pass current jobs record and an action.
| Name | Required | Description | Default |
|---|---|---|---|
| jobs | Yes | Current jobs record: Record<id, jobObject>. Pass {} for empty. | |
| action | Yes | Action to perform. Must include "type" field: "create" | "update" | "delete" | "list" | "search" | "close" | "reopen". See tool description for per-action fields. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description adds that deletion is possible. However, it does not disclose other behavioral traits like auth requirements or side effects beyond listing actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by an instruction, which is concise but could be better structured with bullet points for actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite listing multiple actions, the description lacks details on required fields per action, return values, or error conditions. No output schema exists, so more context is needed for a tool with nested parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining the actions (create updates delete list search close reopen) and their purposes, beyond the schema which only describes fields generically. Per-action fields are hinted but not detailed, so slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages job postings and lists specific actions (create, update, delete, etc.), distinguishing it from sibling tools like ats_manage_candidates which handle candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic instructions (pass current jobs record and action) but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage candidate notes in the ATS. Actions: add (create note on candidate), update (edit note content), list (get all notes for a candidate), delete (remove a note), search (find notes by keyword across one or all candidates), bulk_add (add notes to multiple candidates). Pass the current candidates record.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. "type": "add" | "update" | "list" | "delete" | "search" | "bulk_add". | |
| candidates | Yes | Current candidates record: Record<id, candidateObject>. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's listing of actions (some destructive, some read) adds context but is not critical. The description does not disclose details like rate limits, authorization needs, or the impact of operations beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the purpose. The second sentence lists actions efficiently. However, the phrase 'Pass the current candidates record' is a bit abrupt and could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions) and the absence of an output schema, the description lacks crucial information about return values for each action (e.g., what list returns, confirmation for delete) and does not explain the structure of the 'candidates' record beyond being 'current'. This leaves the agent guessing about expected inputs and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters, but the description goes further by explaining the meaning of each action type (e.g., 'create note on candidate') and emphasizing that the 'candidates' parameter requires the current record. This adds value beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as managing candidate notes in the ATS. It lists six specific actions (add, update, list, delete, search, bulk_add) that distinguish it from sibling tools like ats_manage_candidates or ats_manage_jobs, which handle different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the instruction 'Pass the current candidates record,' hinting at a prerequisite but does not explicitly state when to use each action or when to avoid this tool. The actions are self-explanatory via their names, but no alternatives or exclusions are given for scenarios like searching vs. listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage offers in the ATS. Actions: create (validate & structure), update_status (draft→pending-approval→approved→sent→accepted/declined), delete (remove offer), list (all offers with optional filters), compare (side-by-side offer comparison), validate (check for issues). Returns structured offer data.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: - { type: "create", offer: { candidateId, candidateName, jobId, jobTitle, salary: { base, currency, period, bonus?, equity? }, benefits?, startDate, expirationDate, notes? } } - { type: "update_status", offerId, newStatus: "pending-approval"|"approved"|"sent"|"accepted"|"declined"|"withdrawn"|"negotiating", comment? } - { type: "delete", offerId } - { type: "list", filters?: { candidateId?, jobId?, status? } } - { type: "compare", offers: [existing offer objects] } - { type: "validate", offer: { same as create } } | |
| existingOffers | No | Current offers record (id → offer object). Pass {} for a fresh start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description reinforces this with actions like delete and update_status. It also discloses a status flow (draft→pending-approval→...) and states returns structured offer data, adding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and lists actions efficiently in two sentences. Every sentence adds value, with no redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 actions, nested parameters) and the presence of detailed schema, the description covers each action's purpose and basic flow. It lacks explicit details on return structure or error handling, but the schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters fully. The description adds high-level context (e.g., 'validate (check for issues)') but does not provide additional parameter meaning beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Manage offers in the ATS' and enumerates specific actions (create, update_status, delete, list, compare, validate) each with a brief verb+resource description. It clearly distinguishes from sibling tools (e.g., ats_manage_candidates, ats_manage_jobs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for managing offers but does not explicitly state when to use it versus alternatives. No exclusions or conditions are mentioned; guidance is implicit through the resource name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the ATS hiring pipeline. Given candidates and optional pipeline stage config, returns stage distribution, conversion rates between stages, average time-in-stage, and bottleneck identification. Useful for hiring funnel analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | No | Optional: filter analytics to a specific job ID. | |
| candidates | Yes | Array of candidate objects, each with id, currentStage, jobId, createdAt, updatedAt, and optionally activities[]. | |
| stageOrder | No | Ordered array of stage names. Defaults to: ["applied","screening","phone-screen","interview","final-round","offer","hired","rejected"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the return values (stage distribution, conversion rates, etc.), adding behavioral context beyond the readOnlyHint annotation. It does not mention side effects or permissions, but as a read-only analytics tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains what the tool returns and its use case. The annotations and schema are well-covered, making the description complete for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the description adds minimal additional meaning. It mentions 'given candidates and optional pipeline stage config' but does not elaborate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze the ATS hiring pipeline' and specifies the outputs (stage distribution, conversion rates, time-in-stage, bottlenecks). It distinguishes from sibling tools by focusing on pipeline analytics, not general candidate management or dashboard stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for hiring funnel analysis,' which implies the context of use. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance, but the purpose is clear enough for an agent to infer suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full CRUD for interviews. Actions: create (validate & schedule with conflict detection), update (reschedule/modify), delete (permanent removal), list (filter by candidateId/jobId/status), get (single interview by id). Pass existing interviews record for conflict checks.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: - { type: "create", interview: { candidateId, candidateName, jobId, jobTitle, type, scheduledDate, durationMinutes, interviewers, location?, meetingLink?, notes? } } - { type: "update", interviewId, updates: { partial interview fields } } - { type: "delete", interviewId } - { type: "list", filters?: { candidateId?, jobId?, status? } } - { type: "get", interviewId } | |
| existingInterviews | No | Current interviews record: Record<id, interviewObject>. Pass {} for fresh start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false, but the description states 'permanent removal' for delete actions, which is a direct contradiction. Additionally, no other behavioral traits such as auth requirements or rate limits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, covering all key aspects. It is front-loaded with the core function ('Full CRUD for interviews'). Minor improvement could be structuring the actions list for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of CRUD with multiple actions and nested objects, the description covers the main operations and parameters. It lacks details on return values (no output schema), but conflict detection guidance adds context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by summarizing action structures and clarifying the purpose of existingInterviews for conflict checks. Schema coverage is 100%, so the baseline is 3, but the contextual hint elevates the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Full CRUD for interviews' and lists specific actions (create, update, delete, list, get). This distinguishes it from sibling tools like ats_interview_feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on conflict detection ('Pass existing interviews record for conflict checks') and enumerates filters for the list action. However, it does not explicitly specify when to avoid using this tool or when to prefer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Global search across the ATS. Actions: search (keyword search across candidates, jobs, interviews, offers — scoped optionally), filter_candidates (structured filter by stage/job/tags/score), get_entity (retrieve a single entity by type+id). Pass the full ATS state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Full ATS state: { candidates: Record<id, obj>, jobs: Record<id, obj>, interviews: Record<id, obj>, offers: Record<id, obj> } | |
| action | Yes | Action: "search" (query, scope?, limit?), "filter_candidates" (filters: {stage?, jobId?, tags?, minScore?}), "get_entity" (entityType, entityId). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. Description adds the key constraint that the full ATS state must be passed, which is critical for the agent to understand the input requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an enumeration convey the tool's purpose and actions without redundancy. The purpose is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all three actions with their parameters adequately. However, no output schema or return description is provided, which would be helpful for a tool with multiple action outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning by detailing the three possible action objects and their fields (e.g., filter_candidates includes stage, jobId, tags, minScore), complementing the schema's high-level description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Global search across the ATS' and enumerates three distinct actions (search, filter_candidates, get_entity), distinguishing it from sibling tools that manage specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through 'Global search' phrasing and action descriptions, but lacks explicit when-to-use or when-not-to-use guidance relative to sibling tools like ats_manage_candidates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse multiple resume files at once and run the full algorithmic pipeline on each. Returns raw text, pipeline analysis, keywords, entities, and confidence scores for each file. The LLM client should interpret and structure the results.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Array of files to parse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that results are raw and the LLM must interpret them, adding behavioral context beyond the readOnlyHint annotation. It does not contradict annotations, and it clarifies that no mutation occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: first defines action, second lists outputs, third instructs the LLM. Every sentence earns its place, and critical info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description lists output components (raw text, pipeline analysis, etc.) and tells the LLM to interpret results. This provides sufficient context for an agent to handle the complex output, though more detail on pipeline behavior could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already defines the files parameter with its subfields. The description does not add extra detail beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses multiple resume files and runs a full algorithmic pipeline, which distinguishes it from parse_resume (singular). It specifies the resource (resumes) and action (batch parse), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch use for multiple files but provides no explicit guidance on when to choose this tool over siblings like parse_resume or analyze_resume_comprehensive. No when-not-to-use or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Named Entity Recognition on resume text. Extracts 12 entity types (PERSON, ORGANIZATION, DATE, SKILL, LOCATION, EMAIL, PHONE, URL, EDUCATION_DEGREE, CERTIFICATION, JOB_TITLE, METRIC) with per-entity confidence scores (0-1) and domain-aware disambiguation (e.g., Java the language vs Java the island). Returns classified entities grouped by type, confidence statistics, and ambiguity analysis. 100% algorithmic — no AI calls needed.
| Name | Required | Description | Default |
|---|---|---|---|
| resumeText | Yes | The raw text content of a resume | |
| entityTypes | No | Filter to specific entity types (e.g., ['SKILL', 'JOB_TITLE']). Default: all types. | |
| minConfidence | No | Minimum confidence threshold (0-1) to include an entity. Default: 0 (all entities). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: true, and the description adds valuable behavioral details: '100% algorithmic — no AI calls needed', domain-aware disambiguation, and return of confidence statistics and ambiguity analysis. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (2-3 sentences), front-loaded with the core purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains what is returned: entities grouped by type, confidence scores (0-1), statistics, and ambiguity analysis. Sufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description enhances understanding by listing the 12 entity types explicitly and explaining their grouping, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run Named Entity Recognition on resume text' and lists the 12 entity types with specific examples. It distinguishes from sibling tools like extract_skills_structured by mentioning full NER and domain-aware disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like parse_resume or extract_skills_structured. Usage context is implied through the description, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a resume against a job description using cosine similarity, Jaccard index, TF-IDF overlap, and skill matching. Returns a computed fit tier (strong/moderate/weak/poor), per-skill gap analysis with categories, and actionable gap recommendations. No AI calls — all scoring is algorithmic.
| Name | Required | Description | Default |
|---|---|---|---|
| resumeText | Yes | The raw text content of a resume | |
| jobDescription | Yes | The job description to match against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that all scoring is algorithmic and provides details on outputs (fit tier, gap analysis, recommendations). No contradictions; the description enhances transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no unnecessary words, front-loaded with the most important information (what it does, how it scores, outputs). Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains return values (fit tier, per-skill gap analysis, recommendations). Low parameter count and high schema coverage leave no gaps. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (100% coverage) with concise descriptions. The description adds meaning by specifying the algorithmic methods and the output structure, which goes beyond schema basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it compares resume against job description using specific algorithmic methods (cosine similarity, Jaccard index, TF-IDF overlap, skill matching) and returns fit tier, gap analysis, and recommendations. It distinguishes itself from siblings by explicitly noting 'No AI calls — all scoring is algorithmic.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (algorithmic comparison) and contrasts with AI-based alternatives by stating 'No AI calls.' It does not explicitly list when not to use or name alternatives, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect and structure date ranges, metrics, sections, and work experience from resume text. Returns structured experience entries with titles, organizations, technologies, and achievements extracted algorithmically using NER, date patterns, and TF-IDF. Also detects career progression trajectory. No AI calls.
| Name | Required | Description | Default |
|---|---|---|---|
| resumeText | Yes | The raw text content of a resume |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint and openWorldHint annotations by detailing the algorithmic methods (NER, date patterns, TF-IDF) and explicitly stating 'No AI calls.' It could mention potential limitations or output size, but overall provides good behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, with the key purpose front-loaded. Every sentence adds value: first sentence defines scope, second details returns, third mentions additional detection and method. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (structured experience entries with titles, organizations, technologies, achievements) and mentions career progression trajectory. It could be more complete by specifying the return format or including other detected elements like metrics, but it covers essential expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage and a single parameter described as 'The raw text content of a resume,' the description adds no additional meaning beyond confirming the input is resume text. The baseline of 3 is appropriate as the schema already covers semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects and structures date ranges, metrics, sections, and work experience from resume text. It specifies the methods (NER, date patterns, TF-IDF) and differentiates from siblings by noting 'No AI calls,' making the purpose distinct among sibling tools like parse_resume or extract_experience_structured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage for algorithmic extraction without AI, it does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools to prefer in different contexts, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export parsed resume results to a specified format (JSON or CSV text). Accepts an array of structured resume results and returns formatted output.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Export format: json or csv | |
| results | Yes | Array of parsed resume results with fileName and structured data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and description confirms 'returns formatted output' without contradicting. No additional behavioral context provided beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with no unnecessary words, effectively communicating purpose and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is adequate. It could mention that it operates on previously parsed results, but current is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minor context ('structured resume results' and 'returns formatted output') but doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export parsed resume results' with specific formats (JSON or CSV), distinguishing it from sibling tools that parse, analyze, or assess resumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is for exporting results, but no explicit guidance on when to use this tool versus alternatives like batch_parse_resumes or analyze_resume_comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and structure work experience from resume text using algorithmic analysis only (no AI). Uses date range detection, metric extraction, NER entity classification (job titles, organizations, skills), and heuristic block splitting to produce structured experience entries. Each entry includes detected title, organization, date range, duration estimate, associated metrics/achievements, and technologies. Returns structured data plus overall career statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| resumeText | Yes | The raw text content of a resume |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only (readOnlyHint: true). The description adds rich behavioral context: algorithmic-only processing, date range detection, metric extraction, NER classification, heuristic block splitting, and output details (structured entries, career statistics). This fully discloses the tool's behavior beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states purpose and method, the second lists output content. No redundancy, no fluff. Information is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter, no output schema, and no nested objects, the description covers the tool's purpose, method, and output fields. It could mention edge cases (e.g., empty input) but is otherwise sufficient for a focused extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'resumeText' has full schema coverage (100%) with a clear description ('The raw text content of a resume'). The description adds no extra semantics, but schema coverage is high, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Extract and structure'), resource ('work experience from resume text'), and method ('algorithmic analysis only (no AI)'). It distinguishes from sibling tools like extract_skills_structured and parse_resume by focusing specifically on work experience and specifying a deterministic, non-AI approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for algorithmic, non-AI extraction of work experience, but it does not explicitly state when to prefer this over siblings like parse_resume or extract_skills_structured. No exclusion criteria or alternative recommendations are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract keywords from resume text using TF-IDF analysis, then overlay entity classification (NER) and skill categorization. Returns ranked keywords enriched with entity type, skill category, and confidence scores. No AI calls — all computation is algorithmic.
| Name | Required | Description | Default |
|---|---|---|---|
| topN | No | Number of top keywords to return (default: 40) | |
| resumeText | Yes | The raw text content of a resume |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds that no AI calls are made, and that results include entity type, skill category, and confidence scores. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the method, result, and key characteristics without waste. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description explains return fields (ranked keywords with entity type, skill category, confidence scores) despite no output schema, but it could mention input format constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning to parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts keywords from resume text using TF-IDF analysis, NER, and skill categorization. It distinguishes from sibling tools like extract_skills_structured by specifying the algorithmic, non-AI nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when fast, algorithmic extraction is needed (no AI calls), but does not explicitly state when to avoid or compare to alternatives like extract_skills_structured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and categorize skills from resume text using algorithmic analysis only (no AI). Combines NER entity classification (with disambiguation), TF-IDF keyword ranking, section detection, and frequency-based proficiency estimation. Returns skills organized by 13 categories (programming_language, framework, database, devops_cloud, ml_ai, design, methodology, tool, soft_skill, testing, security, web_frontend, mobile, other) with estimated proficiency levels and supporting evidence. Far more structured than extract_keywords — use this when you need categorized, proficiency-rated skill output.
| Name | Required | Description | Default |
|---|---|---|---|
| resumeText | Yes | The raw text content of a resume | |
| requiredSkills | No | Optional list of skills to specifically check for (returns match/miss status for each) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral detail beyond annotations: no AI used, algorithmic methods (NER, TF-IDF, section detection), frequency-based proficiency estimation. It also discloses the output structure (13 categories, proficiency levels, supporting evidence). No contradiction with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences. Front-loaded with purpose and method, then output structure, then usage comparison. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description carries full burden of explaining return format. It lists categories, proficiency levels, and supporting evidence—sufficient for an agent to understand the output. Minor gap: no mention of edge cases or confidence metrics, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description does not add extra meaning beyond the schema; it focuses on output and methodology. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (extract and categorize), resource (resume text), and method (algorithmic analysis). It distinguishes from sibling extract_keywords by specifying structured, categorized, proficiency-rated output. The explicit list of 13 categories adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly compares to extract_keywords and advises using this tool for categorized, proficiency-rated output. Lacks explicit when-not-to-use guidance, but the contrast is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the full 5-node atomic deconstruction pipeline (Ingestion → Sanitization → Tokenization → Classification → Serialization) on resume text. Returns stage-by-stage metrics, confidence scores, entity classification with disambiguation, data quality assessment, and assumption audit. Use this to understand HOW the parser processes a resume and WHERE confidence is low.
| Name | Required | Description | Default |
|---|---|---|---|
| resumeText | Yes | The raw text content of a resume |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=false (closed world). Description adds details about the pipeline stages and return values, complementing annotations well without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded pipeline stages and return values. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a pipeline inspection tool with one parameter and no output schema, the description thoroughly explains the pipeline stages and the types of metrics returned, making it complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema coverage; the description doesn't add meaning beyond the schema's description of 'raw text content of a resume.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs a specific 5-node pipeline on resume text and lists what it returns (metrics, confidence, etc.). It distinguishes from siblings by focusing on the internal processing steps rather than just extraction or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use this to understand HOW the parser processes a resume and WHERE confidence is low,' providing clear guidance on when to use. It does not mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage and analyze candidates: rank by fit, filter by criteria, recommend pipeline stage changes, compare candidates side-by-side, or get a summary. Operates on candidate data passed in — does not access browser storage.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: rank (sort by fit), filter (by criteria), recommend_stage (suggest stage moves), compare (side-by-side), summarize (overview stats) | |
| criteria | No | Filter/rank criteria: requiredSkills, minimumRating, stages, tags, sortBy, limit | |
| candidates | Yes | Array of candidate objects with id, firstName, lastName, email, currentStage, tags, resumeData, assessmentResult | |
| jobDescription | No | Optional job description for relevance ranking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims actions like 'recommend stage changes' (suggestions, non-destructive), but annotations set destructiveHint=true and readOnlyHint=false, contradicting the suggested behavior. No explanation of actual side effects or state changes is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first lists all supported actions, second states the crucial constraint about browser storage. No redundant information; all content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested candidates, enum actions), the description covers purpose and scope but lacks guidance on when to use each action, output details, and resolves the destructiveHint contradiction. Partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains parameters well. The description adds a plain-language summary of the action enum but does not deepen understanding of criteria, candidates, or jobDescription beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages and analyzes candidates, listing five specific actions (rank, filter, recommend_stage, compare, summarize) and explicitly stating it operates on passed-in data, not browser storage, distinguishing it from sibling tools like ats_manage_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies that the tool works on candidate data passed in, not from storage, which is a key usage condition. However, it does not explicitly state when not to use this tool or name alternative tools for fetching or storing data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a resume file (PDF, DOCX, TXT, MD) or URL and extract text with algorithmic pre-analysis including keyword extraction, metrics detection, section identification, and experience estimation.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Base64-encoded file content, or a URL string when fileType is 'url' | |
| fileType | Yes | File type: pdf, docx, txt, md, or url |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, matching the non-destructive parse operation. The description adds behavioral context beyond annotations: 'algorithmic pre-analysis' and specific extraction capabilities. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action and supported formats. Every word is meaningful; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters and no output schema, the description covers input options and output features reasonably well. However, it does not specify the return format (e.g., JSON structure). Slightly incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds that content can be base64 or URL and lists file types, but this information is already present in the schema. No additional parameter semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Parse a resume file') and resources (PDF, DOCX, TXT, MD, or URL) and lists specific outputs (keyword extraction, metrics detection, section identification, experience estimation). It effectively distinguishes from siblings like batch_parse_resumes or extract_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for initial resume parsing and extraction of pre-analysis features, but does not explicitly state when to use versus alternatives (e.g., extract_keywords, extract_skills_structured). No when-not or context exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send parsed resume results via email using SMTP. Requires SMTP configuration (host, port, user, pass) and recipient email. Sends an HTML summary of all results.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email address | |
| results | Yes | Array of resume results to include | |
| subject | No | Email subject (optional) | |
| smtpHost | Yes | SMTP server host | |
| smtpPass | Yes | SMTP password or app password | |
| smtpPort | No | SMTP server port (default: 587) | |
| smtpUser | Yes | SMTP username/email | |
| smtpSecure | No | Use TLS (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds that it sends an HTML summary. This provides additional behavioral context beyond annotations, though no mention of potential side effects like SMTP connection failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, each adding distinct value: action, requirements, and output format. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain return behavior. It states it sends an HTML summary but omits what the tool returns (e.g., success status, error handling). For a tool with 8 parameters and required credentials, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters. The description adds that results are sent as an HTML summary, but does not elaborate on parameter details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends parsed resume results via email using SMTP. It specifies the action, resource, and method, and among sibling tools there is no other email tool, so differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly requires SMTP configuration and recipient email, indicating when to use. However, it does not provide when-not-to-use or alternative tools for other communication methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3analyze_resume_comprehensiveassess_candidateats_dashboard_statsats_generate_demo_dataats_interview_feedbackats_manage_candidatesats_manage_jobsats_manage_notesats_manage_offersats_pipeline_analyticsats_schedule_interviewats_searchbatch_parse_resumesclassify_entitiescompute_similaritydetect_patternsexport_resultsextract_experience_structuredextract_keywordsextract_skills_structuredinspect_pipelinemanage_candidatesparse_resumesend_emailv0.1.2analyze_resume_comprehensiveassess_candidateats_dashboard_statsats_generate_demo_dataats_interview_feedbackats_manage_candidatesats_manage_jobsats_manage_notesats_manage_offersats_pipeline_analyticsats_schedule_interviewats_searchbatch_parse_resumesclassify_entitiescompute_similaritydetect_patternsexport_resultsextract_experience_structuredextract_keywordsextract_skills_structuredinspect_pipelinemanage_candidatesparse_resumesend_emailv0.1.0analyze_resume_comprehensiveassess_candidateats_dashboard_statsats_generate_demo_dataats_interview_feedbackats_manage_candidatesats_manage_jobsats_manage_notesats_manage_offersats_pipeline_analyticsats_schedule_interviewats_searchbatch_parse_resumesclassify_entitiescompute_similaritydetect_patternsexport_resultsextract_experience_structuredextract_keywordsextract_skills_structuredinspect_pipelinemanage_candidatesparse_resumesend_emailScored across 24 tools
Most tools have distinct purposes, but there is overlap between manage_candidates and ats_manage_candidates, and between extract_keywords and extract_skills_structured. Descriptions clarify the differences, but an agent might still pick the wrong one in ambiguous contexts.
All tools follow a clear verb_noun pattern, with ATS-specific tools consistently prefixed with ats_. Minor exceptions like analyze_resume_comprehensive are still predictable. This pattern makes tool selection intuitive.
With 24 tools, the server is on the heavier side but covers two major domains: resume parsing/analysis and ATS management. Each tool serves a specific sub-function, and while some consolidation is possible, the count is justified for the scope.
The server covers the full HR workflow: resume ingestion and analysis, candidate assessment, ATS CRUD for candidates, jobs, interviews, offers, notes, feedback, plus analytics and demo data. Minor gaps exist (e.g., no direct job board integration), but core operations are well covered.
AI job search MCP — fact-checked jobs, application tracker, alerts. ChatGPT, Claude, Cursor.
Resume builder with native MCP — create and edit resumes from your AI assistant.
MCP for 8,700+ current AI jobs. 13 tools: search, match, salaries, companies, commerce quotes.
Official 100Hires MCP: AI ATS & Recruitment Software for candidates, jobs, applications, interviews.
