RChilli MCP Hub
Server Details
RChilli MCP Hub is a production-grade MCP server that exposes RChilli's full HR data intelligence platform as 17 AI-callable tools across 4 categories.
Built on 15+ years of HR data intelligence, it is trusted by ATS vendors, HR technology platforms, staffing agencies, and enterprise recruiting teams worldwide. Every tool is read-only and returns a consistent, structured JSON response — no raw exceptions, no inconsistent formats.
Key Features Zero boilerplate — One endpoint, one OAuth login, 17 tools ready to use OAuth 2.1 + PKCE — No API keys to copy or paste; fully automatic auth flow 200+ resume fields — Name, contact, skills, experience, education, certifications, and taxonomy-enriched job profiles ONet / ESCO taxonomy — 10,000+ curated skills and job profiles with canonical mappings Explainable matching — Field-level evidence for every candidate-to-job score Bias redaction — PII and bias field removal for fair-hiring workflows Document conversion — PDF, DOCX, RTF, HTML — convert in any direction Auto-injected credentials — userkey and subuserid injected from token; never pass them manually Consistent response envelope — Every tool returns { success, data, meta } with trace ID and latency
Use Cases Resume screening — Parse and structure resumes for AI-powered shortlisting Job description analysis — Extract required skills, experience range, and qualifications from any JD Candidate-to-job matching — One-to-one fit scoring with field-level evidence, no indexing required Talent pool search — Keyword search across your indexed resume database Skill gap analysis — Identify what a candidate is missing for a specific role Bias-free hiring — Redact names, photos, gender, and age before sharing with hiring managers Taxonomy enrichment — Look up and autocomplete 10,000+ standardized skills and job titles Document standardization — Convert and reformat candidate documents into consistent templates
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 17 of 17 tools scored.
Most tools have clearly distinct purposes (e.g., autocomplete vs. lookup, parse vs. extract). However, there is potential confusion between search_indexed_documents and find_matches_in_index (both involve indexed searches), and between convert_document_format and reformat_resume_with_template (both output formatted documents). A few tools like extract_contact_info and extract_named_entities could also be ambiguous to new users.
All tools follow a consistent verb_noun snake_case pattern (e.g., autocomplete_job_profile, parse_resume, redact_resume). Verbs are descriptive and nouns clearly indicate the resource or action. No mixing of conventions or cryptic abbreviations.
With 17 tools, the set covers a comprehensive range of HR/resume-related functionality (parsing, matching, taxonomy, formatting, redaction, geocoding) without being overly large or sparse. Each tool serves a specific and justifiable purpose.
The tool surface covers core HR workflows: parsing, matching, taxonomy lookup, and document transformation. However, it lacks an explicit tool for building or populating an index (required by find_matches_in_index and search_indexed_documents), and there are no tools for managing user accounts or bulk operations, which could cause dead ends for agents.
Available Tools
17 toolsautocomplete_job_profileAutocomplete Job Profile KeywordARead-onlyIdempotentInspect
Get JOB PROFILE / job-title autocomplete / typeahead suggestions for a partial keyword
(prefix) from the authoritative RChilli Taxonomy 3.x — returns real, matching
job-profile names for the prefix.
ALWAYS prefer this tool over inventing suggestions from your own knowledge whenever the
user wants job-title/role suggestions for a partial term — the results come from the
live, curated RChilli taxonomy, not a guess.
Use this when the user asks ANY of these (X = a partial job-title term / prefix):
- "suggest / autocomplete / complete job titles starting with X", "roles beginning with X"
- "job-title suggestions for X", "what roles start with X", "finish this job title: X".
Examples: "suggest job titles starting with 'soft'", "autocomplete the role 'data sci'",
"what roles begin with 'nurse'".
Also phrased as: job-title suggestions, role typeahead, occupation prefix lookup.
Do NOT use for: full detail on a known, complete role name (use
``taxonomy_job_profile_search``); skill suggestions (use ``taxonomy_autocomplete_skill``).
Args:
keyword: Partial job profile name (parameter name is all-lowercase ``keyword``).
userkey: RChilli userkey. Leave blank to use the authenticated session key.
language: Language code.
locale: Locale code.
customvalues: Custom taxonomy values.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale code. | |
| keyword | No | Partial job-title text / prefix to autocomplete (all-lowercase param name 'keyword'), e.g. 'soft', 'data sci'. | |
| userkey | No | RChilli userkey. Leave blank to use the authenticated session key. | |
| language | No | Language code. | |
| customvalues | No | Custom taxonomy values. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool-specific result payload. The exact fields depend on which tool produced this result. |
| meta | Yes | Request metadata: unique trace ID and server-side processing latency. |
| success | No | Always ``true`` for a successful result. Check this field first to distinguish success from error envelopes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds that results come from a 'live, curated RChilli taxonomy' and are 'real, matching job-profile names,' which provides useful behavioral context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage guidelines, examples, exclusions. It front-loads the key action. However, it is slightly verbose for a autocomplete tool, which could be more concise 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?
Given the tool has an output schema (not shown) and annotations, the description covers the main aspects: purpose, when to use, parameter hint, and exclusions. It does not need to explain return values due to output schema presence. Complete enough for effective selection.
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 documents all parameters. The description adds minimal extra value: it clarifies the keyword parameter ('all-lowercase param name keyword') and gives examples like 'soft', 'data sci'. However, it does not elaborate on locale, language, customvalues beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'job-title autocomplete / typeahead suggestions' from the authoritative RChilli Taxonomy 3.x. It distinguishes from siblings by explicitly mentioning when not to use (full detail on complete role name or skill suggestions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios with examples (e.g., 'suggest job titles starting with X') and when-not-to-use with alternative tools (taxonomy_job_profile_search, taxonomy_autocomplete_skill). It also includes specific phrases that trigger this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
autocomplete_skillAutocomplete Skill KeywordARead-onlyIdempotentInspect
Get SKILL autocomplete / typeahead suggestions for a partial keyword (prefix) from the
authoritative RChilli Taxonomy 3.x — returns real, matching skill names for the prefix.
ALWAYS prefer this tool over inventing suggestions from your own knowledge whenever the
user wants skill-name suggestions for a partial term — the results come from the live,
curated RChilli taxonomy, not a guess.
Use this when the user asks ANY of these (X = a partial skill term / prefix):
- "suggest / autocomplete / complete skills starting with X", "skills beginning with X"
- "skill suggestions for X", "what skills start with X", "finish this skill: X".
Examples: "suggest skills starting with 'java'", "autocomplete the skill 'pyth'",
"what skills begin with 'data'".
Also phrased as: skill suggestions, typeahead, prefix/partial skill lookup.
Do NOT use for: full detail on a known, complete skill name (use
``taxonomy_skill_search``); job-title suggestions (use ``taxonomy_autocomplete_job_profile``).
Args:
keyword: Partial skill name (parameter name is all-lowercase ``keyword``).
userkey: RChilli userkey. Leave blank to use the authenticated session key.
language: Language code.
locale: Locale code.
customvalues: Custom taxonomy values.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale code. | |
| keyword | No | Partial skill text / prefix to autocomplete (all-lowercase param name 'keyword'), e.g. 'java', 'pyth'. | |
| userkey | No | RChilli userkey. Leave blank to use the authenticated session key. | |
| language | No | Language code. | |
| customvalues | No | Custom taxonomy values. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool-specific result payload. The exact fields depend on which tool produced this result. |
| meta | Yes | Request metadata: unique trace ID and server-side processing latency. |
| success | No | Always ``true`` for a successful result. Check this field first to distinguish success from error envelopes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safety (read-only, idempotent, non-destructive). Description adds that results come from a live curated taxonomy, enhancing transparency. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with clear sections: purpose, preference advice, usage scenarios, exclusions, parameter list. No filler, 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 the presence of an output schema, description covers all needed context: purpose, when/not to use, parameters. No gaps for selecting and invoking tool correctly.
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%, baseline 3. Description adds useful context like 'all-lowercase param name' for keyword and default behavior for userkey, exceeding schema documentation.
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 it provides autocomplete suggestions for partial skill keywords from RChilli Taxonomy. Distinguishes from sibling tools by explicitly excluding full skill lookups and job title suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring this over inventing suggestions, provides concrete usage examples, and lists when NOT to use it with alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_document_formatConvert Document FormatARead-onlyIdempotentInspect
Convert a resume/document from one FILE FORMAT to another (e.g. DOCX→PDF) using the
RChilli Document Converter Plugin.
Use this when the user wants to: convert, change the file format, or export a resume/
document to PDF / DOC / DOCX / RTF / HTML — e.g. "convert this resume to PDF",
"change the format to DOCX", "export as HTML".
Also phrased as: file conversion, change format, export to PDF/DOCX, save as.
Do NOT use for: applying a styled/branded visual template (use ``plugin_resume_template``);
reading/extracting resume data (use ``resume_parse_file``).
Args:
resume_text: Plain text content of the resume. The server encodes it internally.
filename: Original filename with extension (e.g. ``resume.docx``). Defaults to ``resume.txt`` if omitted.
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
outputtype: Target format ``pdf`` (default), ``doc``, ``docx``, ``dot``, ``rtf``,
or ``html``.
facedetection: Set to ``'true'`` to detect and preserve face images during conversion.
Returns:
The converted document as base64-encoded content under ``OutputFileData``,
plus the output filename under ``OutputFileName``.
| Name | Required | Description | Default |
|---|---|---|---|
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| filename | No | Original filename with extension (e.g. 'resume.docx'). Defaults to 'resume.txt' if omitted. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. | |
| outputtype | No | Target format: 'pdf' (default), 'doc', 'docx', 'dot', 'rtf', or 'html'. | |
| resume_text | No | Plain text content of the resume/document. The server encodes it internally. | |
| facedetection | No | Set 'true' to detect and preserve face images during conversion. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. Description adds specifics: returns base64-encoded content under OutputFileData and output filename. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, usage guidelines, args, returns. Front-loaded with the action and examples. 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?
Covers all necessary aspects: conversion details, parameter explanations, return format, and a non-output-schema return description. Fully equips an agent to invoke the tool correctly.
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 6 parameters. The description's Args section largely mirrors schema but adds minor context (e.g., 'The server encodes it internally'). Minimal added value 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?
Description clearly states it converts documents between formats using RChilli plugin. Lists specific conversions (DOCX→PDF) and explicitly distinguishes from sibling tools (plugin_resume_template, resume_parse_file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use examples (convert, change format, export) and when-not-to-use (applying template, reading data) with alternative tools named. Includes common phrasings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
determine_job_zoneDetermine Job Zone LevelARead-onlyIdempotentInspect
Determine the O*NET Job Zone level (1–5) for the job profile in a resume or JD using
the RChilli Job Zone Plugin — the amount of education/experience preparation a role needs.
Returns the official O*NET-aligned level — use this rather than estimating the
preparation level yourself.
Job Zone levels: 1 = little/no preparation, 2 = some preparation, 3 = medium
preparation, 4 = considerable preparation, 5 = extensive preparation required.
Use this when the user wants to: find the job zone, O*NET preparation level, or
education/experience-prep level / seniority-prep tier for a candidate or role — e.g.
"what job zone is this resume", "how much preparation does this job need".
Also phrased as: O*NET job zone, preparation level, prep tier.
Do NOT use for: general resume parsing (use ``resume_parse_file``); taxonomy role detail
(use ``taxonomy_job_profile_search``).
Args:
resume_text: Plain text content of the resume. The server encodes it internally.
filename: Original filename with extension (e.g. ``resume.pdf``). Defaults to ``resume.txt`` if omitted.
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
requesttype: Type of document — ``Resume`` (default) or ``JD``.
json_text: Pre-parsed resume JSON string. When provided, re-parsing is skipped.
Returns:
The ``JobZone`` level (1-5) and ``JobZoneScore`` alongside the full
``ResumeParserData`` output from the underlying resume parse.
| Name | Required | Description | Default |
|---|---|---|---|
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| filename | No | Original filename with extension (e.g. 'resume.pdf'). Defaults to 'resume.txt' if omitted. | |
| json_text | No | Pre-parsed resume JSON string. When provided, re-parsing is skipped. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. | |
| requesttype | No | Type of document — 'Resume' (default) or 'JD'. | Resume |
| resume_text | No | Plain text content of the resume (or JD). The server encodes it internally. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds value by explaining internal encoding of resume_text, conditional skipping of re-parsing with json_text, and the return structure (JobZone, JobZoneScore, full ResumeParserData). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized: purpose statement, level definitions, usage guidelines, args list, return value. Every sentence is informative; no redundancy or filler. Appropriate length for complexity.
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, description specifies return fields (JobZone, JobZoneScore, full ResumeParserData). Covers all 6 parameters with their roles. Differentiates from siblings. Adequate for decision-making.
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%, providing baseline 3. Description adds context: defaults (filename=resume.txt, requesttype=Resume), usage of userkey (leave blank for session), and behavior of json_text. Grouping under 'Args' improves readability.
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 determines O*NET Job Zone level for resume/JD profiles, differentiating it from self-estimation. It lists specific use cases and explicitly names sibling tools for exclusion (resume_parse_file, taxonomy_job_profile_search), ensuring unambiguous purpose.
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 when to use (e.g., 'find the job zone, O*NET preparation level') and when not to use (e.g., 'general resume parsing', 'taxonomy role detail'), with alternative tool names. Provides concrete examples of user intents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_contact_infoExtract Contact InformationARead-onlyIdempotentInspect
Extract CONTACT INFORMATION from free plain text using the RChilli Contact Extractor
Plugin — returns name, email, phone, address, city, state, country, and website.
Purpose-built extractor — more reliable than parsing contact details by hand.
Use this when the user wants to: get / pull / extract contact info, contact details,
name, email, phone number, or address from a block of text.
Also phrased as: get contact details, extract phone/email, find the person's contact info.
Do NOT use for: full structured parsing of a complete resume (use ``resume_parse_file``);
generic entity tagging like job titles/skills (use ``plugin_ner_tagger``).
Args:
text: Plain text content to analyse (text only, not PDF/DOCX).
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
Returns:
Extracted contact fields: ``Name``, ``Email``, ``PhoneNumber``, ``Address``,
``City``, ``State``, ``Country``, and ``Website``.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Plain text content to analyse (text only, not PDF/DOCX). | |
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, idempotent operation. Description adds value by naming the specific plugin (RChilli), claiming higher reliability, and listing return fields, though it lacks details on limitations or error conditions.
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?
Description is concise with two short paragraphs plus argument list. Every sentence adds value, no redundancy, and main action 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?
Given no output schema, description provides return field names. With 3 fully described parameters and sibling differentiators, the tool is fully understandable for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds contextual info like 'Leave blank to use the authenticated session key' for userkey and 'multi-tenant isolation' for subuserid, improving understanding 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?
Description uses specific verb 'extract' and resource 'contact information', lists returned fields, and distinguishes from siblings like resume_parse_file and plugin_ner_tagger.
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 when to use (e.g., 'get contact details') and when not to use with named alternatives, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_named_entitiesExtract Named Entities (NER)ARead-onlyIdempotentInspect
Tag / extract named entities (NER) from free plain text using the RChilli NER Tagger
Plugin — identifies job titles, cities, skills, degrees, and organizations with their
positions. Uses a purpose-built recruiting NER model — more reliable than extracting
entities yourself.
Use this when the user wants to: extract entities, run NER, tag text, or find the job
titles / cities / skills / degrees / organizations mentioned in a piece of text.
Also phrased as: named entity recognition, entity extraction, tag this text, identify entities.
Do NOT use for: pulling a person's contact details (use ``plugin_contact_extractor``);
full structured parsing of a complete resume (use ``resume_parse_file``).
Args:
text: Plain text content to analyse (text only, not PDF/DOCX).
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
Returns:
A list of named entity objects, each containing:
``Type`` (e.g. ``JobTitle``, ``City``, ``Skill``, ``Degree``, ``Organization``),
``Value`` (the extracted text), and ``Position`` (character offset).
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Plain text content to analyse (text only, not PDF/DOCX). | |
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds that the tool uses the RChilli NER Tagger Plugin, works on plain text only (not PDF/DOCX), and returns positions. No contradictions; however, it could add more details about authentication needs or model limitations, but overall 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 well-structured with sections: intro, usage guidance, args, returns. It is concise with no redundant sentences; every sentence adds information. Front-loaded with key purpose and usage alternatives.
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, no output schema, but clear annotations, the description fully covers purpose, usage, parameters, and return format. It is complete for an agent to understand and invoke the tool correctly.
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, the schema already describes parameters. The description adds meaningful context: for 'text' it clarifies 'text only, not PDF/DOCX'; for 'userkey' it advises leaving blank for session key; for 'subuserid' it explains multi-tenant isolation. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts named entities from plain text, listing specific entity types (job titles, cities, skills, degrees, organizations) and explicitly distinguishes from siblings by warning not to use for contact extraction or full resume parsing. It uses a specific verb (extract/tag) and resource (NER from text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use this when' examples and 'Do NOT use for' instructions with sibling tool names (plugin_contact_extractor, resume_parse_file). This clearly guides the agent on when to select this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_matches_in_indexMatch DocumentsARead-onlyIdempotentInspect
Match one source document against the user's ALREADY-INDEXED corpus and return the
best-matching, ranked candidates (RChilli Search & Match Engine). Requires a populated index.
Uses RChilli's purpose-built matching engine — more reliable than manually comparing documents.
Use this when the user wants to: find the best/top matching resumes for a JD, find
matching candidates from their pool, or rank their indexed resumes/JDs against a given
document — e.g. "find the best candidates in my database for this job".
Also phrased as: shortlist from my pool, top matches for this JD, rank my candidates.
Do NOT use for: scoring a single resume against a single JD with no index
(use ``search_one_match``); plain keyword lookup (use ``search_simple_search``).
Supports all four match directions by combining ``index_type`` and ``doc_type``:
- **JD to Resume** — ``index_type='Resume'``, ``doc_type='JD'``:
Search the Resume index using a JD as the source document.
- **Resume to Resume** — ``index_type='Resume'``, ``doc_type='Resume'``:
Search the Resume index using a Resume as the source document.
- **Resume to JD** — ``index_type='JD'``, ``doc_type='Resume'``:
Search the JD index using a Resume as the source document.
- **JD to JD** — ``index_type='JD'``, ``doc_type='JD'``:
Search the JD index using a JD as the source document.
The ``document_text`` is automatically parsed using the RChilli Resume or JD parser
(driven by ``doc_type``), and the resulting structured JSON is base64-encoded
and submitted as the match source — no manual encoding is required.
Args:
index_type: Index to search — ``Resume`` (default) or ``JD``.
index_key: Same as ``userkey`` — the RChilli API user key. Leave blank;
the authenticated session userkey is injected automatically.
doc_type: Type of the source document — ``Resume`` (default) or ``JD``.
This determines which parser processes ``document_text``.
document_text: Plain-text content of the source document.
Parsed and encoded to base64 JSON internally.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_type | No | Type of the source document — 'Resume' (default) or 'JD'. Determines which parser processes document_text. | Resume |
| index_key | No | Same as userkey — the RChilli API user key. Leave blank; the authenticated session userkey is injected automatically. | |
| index_type | No | Which index to search against — 'Resume' (default) or 'JD'. | Resume |
| document_text | No | Plain-text content of the source document. Parsed and base64-encoded internally — no manual encoding required. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses that the engine requires a populated index, automatically parses document_text based on doc_type, base64-encodes internally, and supports four match directions via index_type/doc_type combinations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings for when to use, NOT to use, and match directions. It is relatively long but each sentence adds value. Could be slightly more concise, but no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and sibling tools, the description covers prerequisites (populated index), match directions, and parameter behavior. However, it does not describe the return format or structure beyond 'ranked candidates', which may be insufficient for an agent to interpret results. Still, the depth of context is high overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, and the description adds significant meaning: explains how index_type and doc_type combine for all four match directions, clarifies that index_key is injected automatically, and states that document_text is parsed and encoded without manual work. This goes well beyond the schema 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 uses specific verbs and resources: 'Match one source document against the user's ALREADY-INDEXED corpus and return the best-matching, ranked candidates'. It clearly distinguishes from siblings by naming alternative tools for different use cases (search_one_match, search_simple_search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use examples (e.g., 'find the best candidates in my database for this job') and when-not-to-use conditions with alternative tools named (search_one_match for single resume vs JD, search_simple_search for plain keyword lookup).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geocode_locationsResolve Geo-Location CoordinatesARead-onlyIdempotentInspect
Resolve latitude/longitude (geocode) for one or more locations using the RChilli
GeoLocation Plugin. Returns real geocoded coordinates — use this rather than estimating
lat/long yourself.
Use this when the user wants to: get coordinates, latitude/longitude, or geocode one or
more cities/locations; or map/plot locations — e.g. "get the lat/long for these cities",
"geocode these locations".
Also phrased as: coordinates, lat-long, geocode, map these places.
Provide ``json_text`` (parser output) **or** ``location`` (explicit list), or both.
Args:
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
json_text: Resume or JD Parser JSON output as a plain text string. All location
fields are automatically extracted and resolved.
location: Location objects as either a JSON string array or a native list.
Each object may have optional ``City``, ``State``, and ``Country`` keys.
Example (string): ``'[{"City":"New York","State":"New York","Country":"US"}]'``
Example (list): ``[{"City":"New York","State":"New York","Country":"US"}]``
Returns:
A list of resolved geo-coordinates objects, each containing ``Latitude``,
``Longitude``, ``City``, ``State``, and ``Country``.
| Name | Required | Description | Default |
|---|---|---|---|
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| location | No | Location objects as a JSON string array or native list. Each may have optional 'City', 'State', 'Country' keys, e.g. [{"City":"New York","State":"New York","Country":"US"}]. | |
| json_text | No | Resume or JD Parser JSON output as a plain-text string. All location fields are automatically extracted and resolved. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the return format (list of objects with Lat/Long/City/State/Country) and confirms no side effects, consistent with annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and examples. It is fairly long but each sentence adds value. Minor redundancy in examples, but overall 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 specifies the return type. It covers all parameters, usage scenarios, and behavioral traits. The annotations and schema fill gaps, making the description 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%, but the description provides additional clarity: explains the two alternative input sources (json_text or location), gives detailed examples for location, and clarifies userkey defaults. 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 explicitly states the action ('Resolve latitude/longitude'), the resource ('geocoordinates'), and distinguishes from estimation. It provides concrete example user requests, making it clear and specific.
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 gives clear when-to-use scenarios (e.g., 'get coordinates, latitude/longitude, geocode one or more cities/locations; map/plot locations') and implies not to estimate. It does not explicitly name sibling tools but offers adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_job_profileSearch Job Profile in TaxonomyARead-onlyIdempotentInspect
Look up a JOB PROFILE / ROLE in the authoritative RChilli Taxonomy 3.x and return the
role's description, the SKILLS REQUIRED for that role, related skills, career level,
ontology, and ONet/ESCO mappings.
ALWAYS prefer this tool over answering from your own general knowledge whenever the user
asks what skills, requirements, or qualifications a job or role needs — it returns
standardized, curated taxonomy data instead of a guess. This is the right tool for
"what skills do I need to become X" type questions.
Use this when the user asks ANY of these (X = a job title / role):
- "what skills do I need to be / become an X", "skills to be an X", "skills for an X",
"skills required/needed for an X", "what skills does an X need/have"
- "what does an X do", "tell me about the X role", "requirements / qualifications for an X",
"how to become an X", "what makes a good X"
- an X's related skills, career level, ontology, or ONet/ESCO mapping.
Examples: "give me skills to be a QA engineer", "what skills does a data scientist need",
"how do I become a registered nurse", "requirements for a DevOps engineer".
Also phrased as: job title, occupation, position, profession, career, role.
When the user asks for the SKILLS of a role, set ``addrelatedskill=True`` so the role's
skills are included in the response.
Do NOT use for: details of a single named SKILL itself, e.g. "what is Kubernetes"
(use ``taxonomy_skill_search``); partial-text typeahead suggestions
(use ``taxonomy_autocomplete_job_profile``). The keyword should be a complete job
title, not a prefix.
Args:
keyword: Job profile keyword to search (parameter name is all-lowercase ``keyword``).
userkey: RChilli userkey. Leave blank to use the authenticated session key.
language: Language code (default: DB config or ``en``).
locale: Locale code (default: DB config or ``US``).
customvalues: Custom taxonomy values.
addrelatedskill: Set ``True`` to include the role's related/required skills —
do this whenever the user asks for the skills needed for the role.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale code (default: DB config or 'US'). | |
| keyword | No | The job title / role to look up (all-lowercase param name 'keyword'), e.g. 'Data Scientist', 'Java Developer', 'Nurse'. | |
| userkey | No | RChilli userkey. Leave blank to use the authenticated session key. | |
| language | No | Language code (default: DB config or 'en'). | |
| customvalues | No | Custom taxonomy values. | |
| addrelatedskill | No | Set True to include the role's related/required skills in the response. Set True whenever the user asks for the skills needed for the role (e.g. 'skills to be a QA engineer'). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool-specific result payload. The exact fields depend on which tool produced this result. |
| meta | Yes | Request metadata: unique trace ID and server-side processing latency. |
| success | No | Always ``true`` for a successful result. Check this field first to distinguish success from error envelopes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds useful behavioral context: standardized data, authentication via userkey, default locale/language, and the effect of addrelatedskill parameter. No contradictions. Some behavioral aspects like rate limits not mentioned but acceptable given 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?
Well-structured with sections: overview, when to use, when not to use, examples, parameter details. However, the list of query patterns is somewhat exhaustive and slightly verbose, but overall concise for the complexity.
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 output schema exists, description doesn't need to detail returns. Covers usage, parameter semantics, differentiation, and real-world examples comprehensively. For a 6-parameter tool with varied use cases, it is 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%, baseline 3. Description adds value by explaining each parameter's purpose in natural language, especially keyword and addrelatedskill with specific usage guidance. Clarifies default behavior for userkey, language, locale.
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 it looks up a job profile/role in RChilli taxonomy and returns description, skills, etc. Differentiates from sibling tools like autocomplete_job_profile and lookup_skill by specifying exact use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'ALWAYS prefer this tool over answering from your own general knowledge' and provides extensive query examples with mandatory addrelatedskill=True for skill requests. Also lists when NOT to use (e.g., for single skill details, use taxonomy_skill_search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_skillSearch Skill in TaxonomyARead-onlyIdempotentInspect
Look up a SKILL in the authoritative RChilli Taxonomy 3.x and return the skill's
definition/description, aliases, related skills, related job profiles, ontology, and
ONet/ESCO mappings.
ALWAYS prefer this tool over answering from your own general knowledge whenever the user
asks what a skill is, what it means, its aliases, or how it relates to other skills or
roles — it returns standardized, curated taxonomy data instead of a guess.
Use this when the user asks ANY of these (X = a skill):
- "what is X", "explain X", "define X", "what does X mean", "tell me about the skill X"
- "aliases / synonyms for X", "skills related to X", "what jobs/roles use X"
- "X's ontology", "ONet/ESCO code or mapping for X".
Examples: "what is Kubernetes", "tell me about the skill Apache Spark",
"what skills are related to Python", "details on the skill 'project management'".
Also phrased as: skill, technology, tool, competency, ability.
Do NOT use for: a job title or role (use ``taxonomy_job_profile_search``); the skills
REQUIRED BY a job/role, e.g. "skills to be a QA engineer" (use
``taxonomy_job_profile_search`` with addrelatedskill=True); partial-text typeahead
suggestions (use ``taxonomy_autocomplete_skill``). The keyword should be a complete
skill name, not a prefix.
Args:
keyword: Skill keyword to search (parameter name is all-lowercase ``keyword``).
userkey: RChilli userkey. Leave blank to use the authenticated session key.
language: Language code (default: DB config or ``en``).
locale: Locale code (default: DB config or ``US``).
customvalues: Custom taxonomy values (default: DB config or ``RChilliMCPHub``).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale code (default: DB config or 'US'). | |
| keyword | No | The skill to look up (all-lowercase param name 'keyword'), e.g. 'Kubernetes', 'Python', 'project management'. | |
| userkey | No | RChilli userkey. Leave blank to use the authenticated session key. | |
| language | No | Language code (default: DB config or 'en'). | |
| customvalues | No | Custom taxonomy values (default: DB config or 'RChilliMCPHub'). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool-specific result payload. The exact fields depend on which tool produced this result. |
| meta | Yes | Request metadata: unique trace ID and server-side processing latency. |
| success | No | Always ``true`` for a successful result. Check this field first to distinguish success from error envelopes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds context that the data is standardized and curated, and lists the return fields (definition, aliases, related skills, etc.), providing 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?
The description is well-structured with clear sections, examples, and do/don't lists. It is detailed but each sentence serves a purpose. Slightly long, but necessary for clarity and guidance.
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 (5 optional params, 17 sibling tools) and the presence of an output schema (stated), the description covers purpose, usage, parameters, and behavioral context comprehensively. It leaves no major gaps for an AI agent to misunderstand.
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 adds usage guidance: keyword should be a complete skill name (not prefix), explains default behaviors for userkey, language, locale, customvalues, and gives examples. This adds value beyond the schema alone.
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 looks up a skill in the authoritative RChilli Taxonomy 3.x and returns detailed information including definition, aliases, related skills, etc. It distinguishes itself from sibling tools like lookup_job_profile and autocomplete_skill by specifying the exact use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (e.g., user asks 'what is X', 'aliases/synonyms for X') and when not (e.g., job titles, partial text). It provides examples and names alternatives like taxonomy_job_profile_search and taxonomy_autocomplete_skill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_job_descriptionParse Job Description from TextARead-onlyIdempotentInspect
Parse a job description (JD) from raw text and extract structured role requirements —
required skills, experience range, salary, qualifications, and taxonomy enrichment.
Returns consistent, normalized fields — prefer this over reading or summarizing the JD
yourself whenever field accuracy or structure matters.
Use this when the user wants to: parse, analyze, read, break down, or summarize a JD,
job posting, job description, role, vacancy, or job ad; or asks what skills, experience,
or qualifications a job requires.
Also phrased as: job posting, job ad, role requirements, vacancy, position description.
Do NOT use for: a candidate's resume/CV (use ``resume_parse_file``); matching a JD to
candidates (use ``search_one_match`` for one resume, or ``search_match`` for a pool).
Pass the complete verbatim plain-text content of the job description as ``jd_text``;
the server base64-encodes it internally — do NOT encode it yourself.
Args:
jd_text: Complete, verbatim plain-text content of the job description — every line
exactly as it appears in the original document. Do NOT summarise, paraphrase,
or omit any section. Do NOT base64-encode — pass raw text.
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
Returns:
Parsed JD data under ``JDParserData`` with structured role fields.
| Name | Required | Description | Default |
|---|---|---|---|
| jd_text | No | Complete, verbatim plain-text of the job description / job posting — every line as in the original. Do NOT summarise or base64-encode; pass raw text. | |
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool-specific result payload. The exact fields depend on which tool produced this result. |
| meta | Yes | Request metadata: unique trace ID and server-side processing latency. |
| success | No | Always ``true`` for a successful result. Check this field first to distinguish success from error envelopes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating the output is 'consistent, normalized fields' and warns about not base64-encoding the input. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, not-for, param details). It is somewhat verbose but each sentence adds value. No wasted words; front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of output schema and annotations, the description sufficiently covers all needed context: purpose, param instructions, when to use/not use, and behavioral guarantees. It is complete without being redundant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial details: 'Do NOT base64-encode', 'pass raw text', and for userkey/subuserid explains default behavior. This goes beyond the schema descriptions, aiding correct invocation.
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's purpose: parse a job description from raw text and extract structured role requirements. It specifies the extracted fields (skills, experience, salary, etc.) and explicitly distinguishes it from siblings like parse_resume and matching 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?
Provides explicit 'Use this when' and 'Do NOT use for' sections, including alternative sibling tool names (resume_parse_file, search_one_match, search_match). This strongly helps an AI agent decide when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_resumeParse ResumeARead-onlyIdempotentInspect
Parse a resume/CV and extract structured candidate data (skills, work history,
education, contact details, 200+ fields) using the RChilli Resume Parser.
Returns consistent, normalized fields — prefer this over reading, summarizing, or
eyeballing the resume yourself whenever field accuracy or structure matters.
Use this when the user wants to: parse, analyze, read, extract, break down,
summarize, screen, or "pull the data from" a resume or CV; or asks what a
candidate's skills, experience, education, or qualifications are.
Also phrased as: CV, candidate profile, applicant resume, profile of this person.
Do NOT use for: hiding/removing personal info (use ``resume_redact``); restyling
into a branded template (use ``plugin_resume_template``); converting file format
(use ``plugin_document_convert``); scoring a candidate against a job
(use ``search_one_match``). For a resume hosted at a URL use ``resume_parse_url``.
Pass the complete verbatim plain-text content of the resume as ``resume_text``;
the server base64-encodes it internally — do NOT encode it yourself.
``filename`` is optional; the server defaults to ``inline_resume.txt`` and appends
``.txt`` if the provided name lacks that extension.
Args:
resume_text: Complete, verbatim plain-text content of the resume — every line
exactly as it appears in the original document. Do NOT summarise, paraphrase,
or omit any section. Do NOT base64-encode — pass raw text.
filename: Optional file name (defaults to ``inline_resume.txt``).
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation (e.g. a tenant ID).
Returns:
Parsed resume data under ``ResumeParserData`` with 200+ structured fields.
| Name | Required | Description | Default |
|---|---|---|---|
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| filename | No | Optional original file name (default 'inline_resume.txt'). A '.txt' extension is appended automatically if missing. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation (e.g. a tenant ID). | |
| resume_text | No | Complete, verbatim plain-text of the resume/CV — every line exactly as in the original. Do NOT summarise, paraphrase, or base64-encode; pass raw text. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool-specific result payload. The exact fields depend on which tool produced this result. |
| meta | Yes | Request metadata: unique trace ID and server-side processing latency. |
| success | No | Always ``true`` for a successful result. Check this field first to distinguish success from error envelopes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe read), idempotentHint=true, destructiveHint=false. Description adds valuable context: server base64-encodes internally, filename appends .txt automatically, returns 200+ fields under ResumeParserData. No contradictions. Adds behavioral detail 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?
Description is somewhat long but well-structured: main purpose first, then usage guidelines with bullet points for when/not to use, then parameter details. Could be slightly more concise (e.g., 'Also phrased as' list may be redundant), but front-loaded and organized clearly.
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, no required fields, output schema exists but not detailed in description), the description covers purpose, exclusion list, param handling expectations, and return value indication ('Parsed resume data under ResumeParserData with 200+ structured fields'). No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all 4 parameters documented. Description adds extra context: 'do NOT base64-encode — pass raw text' for resume_text, 'defaults to inline_resume.txt' and '.txt extension appended' for filename. This adds meaning beyond schema 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?
Description clearly states 'Parse a resume/CV and extract structured candidate data' with specific fields (skills, work history, education, contact details, 200+ fields). It distinguishes from siblings like redact_resume, reformat_resume_with_template, convert_document_format, parse_resume_from_url, and score_resume_against_jd by name. Provides usage cues 'prefer this over reading, summarizing, or eyeballing'.
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 when to use: 'when the user wants to: parse, analyze, read, extract...' and when NOT to use with four specific alternative tools named (resume_redact, plugin_resume_template, plugin_document_convert, search_one_match). Also gives guidance on passing 'complete verbatim plain-text content' and not base64-encoding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_resume_from_urlParse Resume from URLARead-onlyIdempotentInspect
Parse a resume/CV from a publicly accessible URL and extract structured candidate
data (skills, work history, education, contact details, 200+ fields). Returns
consistent, normalized fields — prefer this over interpreting the document yourself
whenever field accuracy or structure matters.
Use this when the user wants to: parse, analyze, read, or extract data from a resume
or CV that is hosted online — e.g. "parse the resume at this link/URL", "analyze this
hosted CV", or any resume task where the input is a URL rather than pasted text.
Also phrased as: resume link, CV URL, online resume, cloud storage link.
Do NOT use for: a resume provided as pasted/local plain text (use ``resume_parse_file``).
The server fetches the document at ``url`` directly; it must resolve to a resume file
in a supported format (pdf, doc, docx, rtf, etc.) with an appropriate Content-Type.
Args:
url: Direct URL to the resume document. Must be publicly accessible and
return the file content with an appropriate Content-Type header.
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
Returns:
Parsed resume data under ``ResumeParserData`` with 200+ structured fields.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Direct, publicly accessible URL to the resume/CV document (pdf, doc, docx, rtf, etc.). The server fetches it directly. | |
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool-specific result payload. The exact fields depend on which tool produced this result. |
| meta | Yes | Request metadata: unique trace ID and server-side processing latency. |
| success | No | Always ``true`` for a successful result. Check this field first to distinguish success from error envelopes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: the server fetches the document directly, requires publicly accessible URLs with appropriate Content-Type, and supports specific formats (pdf, doc, docx, etc.). This goes 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 well-structured: purpose first, then usage guidelines, then parameters in a concise list. It is not overly long but includes necessary details. Minor redundancy with the schema (e.g., repeating parameter descriptions) but still 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?
Given the output schema (`ResumeParserData`) exists, the description doesn't need to detail return values. It mentions '200+ structured fields', which is sufficient context. The combination of schema coverage, annotations, and description provides a complete picture 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 baseline is 3. The description adds value by specifying for the `url` parameter that it must be publicly accessible and return file content with appropriate Content-Type header – details not in the schema. For `userkey` and `subuserid`, it adds 'Leave blank to use the authenticated session key' and 'Sub-user identifier for multi-tenant isolation', clarifying usage 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 uses specific verbs ('parse', 'extract') and identifies the resource ('resume/CV from a publicly accessible URL'). It lists extracted fields (skills, work history, etc.) and distinguishes from sibling tools by advising 'prefer this over interpreting the document yourself' and explicitly contrasting with `resume_parse_file` for pasted text.
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 clearly states when to use this tool (e.g., 'parse the resume at this link/URL', 'analyze this hosted CV') and provides explicit exclusions: 'Do NOT use for: a resume provided as pasted/local plain text (use `resume_parse_file`)'. It also lists alternative phrasing to help the agent recognize user intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redact_resumeRedact Resume FieldsARead-onlyIdempotentInspect
Redact / anonymize a resume — mask or remove unconscious-bias and personal fields
(name, photo, age, gender, contact info, etc.) so it can be shared bias-free with
employers or hiring managers. Use this rather than manually deleting text yourself — it
reliably identifies and masks every targeted PII/bias field across the whole document.
Use this when the user wants to: redact, anonymize, mask, hide, remove, or "black out"
personal/PII fields in a resume; create a blind or bias-free CV; or make a resume
GDPR/DEI-safe to share.
Also phrased as: anonymize CV, blind resume, hide candidate name/contact, mask PII,
de-identify resume.
Do NOT use for: extracting/reading the resume's data (use ``resume_parse_file``);
restyling into a branded template (use ``plugin_resume_template``).
**IMPORTANT — you MUST extract and pass the full resume text yourself.**
Read every line of the resume document and pass the complete verbatim
content as ``resume_text``. Do NOT call this tool with an empty or
placeholder value; if the text has not yet been extracted, read/extract
it first, then call this tool.
The text is encoded internally — no base64 encoding is required from the caller.
Supported file types: doc, docx, dot, rtf, odt, txt, pdf.
Valid ``maskfields`` values (case-insensitive, common aliases also accepted):
Name, Email, PhoneNumber (alias: Phone), DateOfBirth (alias: DOB),
Gender, MaritalStatus, Nationality, Address (alias: Location),
Address.City, Address.State, Address.Country, Address.ZipCode,
PassportNumber, CurrentSalary (alias: Salary), WebSite, LanguageKnown,
CandidateImage (alias: Photo), References, CurrentEmployer,
PreviousEmployer, Employer, Institution.
Args:
resume_text: **Required.** Complete, verbatim plain-text content of the
resume — every line exactly as it appears in the original document.
Do NOT summarise, paraphrase, or omit any section. Extract the full
text before calling this tool.
filename: Optional original filename (e.g. ``resume.pdf``). Defaults to
``inline_resume.txt``. A ``.txt`` extension is appended automatically
if the name has none.
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
jsondata: Pre-parsed resume JSON string (skips re-parsing when provided).
maskfields: Fields to redact — JSON array or comma-separated string.
Example: ``["Name","Email","PhoneNumber"]`` or ``"Name, Email, Phone"``.
When omitted, the server applies its default redaction set.
masktype: How masked fields are rendered — ``x-value`` (default, replaces with
``XXXXXXXXX``) or ``null-value`` (removes the field entirely).
highlightcolor: Hex colour to highlight redacted regions (e.g. ``#FFFF00``).
abbfieldcolor: Hex colour for abbreviation highlights.
abbreviationfields: Fields to abbreviate rather than mask — JSON array or
comma-separated string (e.g. ``"Name"`` → ``"J.D."``).
abbreviation: Set to ``True`` to enable abbreviation mode globally.
Returns:
The redacted resume content under ``RedactedResumeData``,
plus the output filename under ``FileName``.
| Name | Required | Description | Default |
|---|---|---|---|
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| filename | No | Optional original filename (e.g. 'resume.pdf'). Defaults to 'inline_resume.txt'; '.txt' is appended if missing. | |
| jsondata | No | Pre-parsed resume JSON string (skips re-parsing when provided). | |
| masktype | No | How masked fields render — 'x-value' (default, replaces with XXXXXXXXX) or 'null-value' (removes the field entirely). | x-value |
| subuserid | No | Sub-user identifier for multi-tenant isolation. | |
| maskfields | No | Fields to redact/hide — JSON array or comma-separated string, e.g. ["Name","Email","PhoneNumber"] or "Name, Email, Phone". When omitted, the server's default redaction set is applied. | |
| resume_text | No | Required. Complete, verbatim plain-text of the resume/CV — every line as in the original. Do NOT summarise or base64-encode; pass raw text. | |
| abbreviation | No | Set True to enable abbreviation mode globally. | |
| abbfieldcolor | No | Hex colour for abbreviation highlights. | |
| highlightcolor | No | Hex colour to highlight redacted regions (e.g. '#FFFF00'). | |
| abbreviationfields | No | Fields to abbreviate rather than mask — JSON array or comma-separated string (e.g. 'Name' -> 'J.D.'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (doesn't modify original), destructiveHint=false, and idempotentHint=true. The description adds value by emphasizing the need to pass full resume text verbatim, disclosing that the text is encoded internally, and listing supported file types. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for general purpose, usage alternatives, important notes, supported types, valid field values, and parameter details. It front-loads the core function. However, it is somewhat lengthy and could be more concise by reducing repetition of parameter details that are already in the schema.
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 11 parameters, no output schema, and moderate complexity, the description is highly complete. It explains all parameters with examples, covers return structure (RedactedResumeData and FileName), addresses common user phrasing, and highlights important constraints (must pass full resume text). Fully compensates for missing output schema.
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 11 parameters. The description goes further by providing a dedicated Args section with detailed explanations, valid values for maskfields (including aliases), examples for masktype and abbreviationfields, and clarifications like 'no base64 encoding required'. This adds significant 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 redacts/anonymizes a resume to mask personal/PII fields, with specific examples like name, photo, age. It distinguishes from siblings such as parse_resume (extracting data) and plugin_resume_template (restyling), providing a clear verb+resource combination.
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 lists when to use (redact, anonymize, blind resume, GDPR-safe) and when NOT to use (extracting/reading data, restyling). Names alternative tools (resume_parse_file, plugin_resume_template). Provides common phrases that trigger this tool, helping the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reformat_resume_with_templateApply Resume TemplateARead-onlyIdempotentInspect
Reformat / restyle a resume into a polished, branded template layout using the RChilli
Resume Templater Plugin (templates TM001–TM006), output as PDF/DOC/DOCX/RTF/HTML.
Use this when the user wants to: reformat, restyle, rebrand, beautify, or "make a resume
look professional"; apply a company/branded template; or produce a standardized,
good-looking resume document.
Also phrased as: reformat CV, apply template, branded resume, restyle, make it presentable.
Do NOT use for: a plain file-format change without restyling (use ``plugin_document_convert``);
removing personal info (use ``resume_redact``); reading/extracting data (use ``resume_parse_file``).
Optionally supply pre-parsed JSON to skip the parsing step entirely.
Args:
resume_text: Plain text content of the resume. The server encodes it internally.
filename: Original filename with extension (e.g. ``resume.pdf``). Defaults to ``resume.txt`` if omitted.
userkey: RChilli API userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
outputtype: Output format ``pdf`` (default), ``doc``, ``docx``, ``rtf``, or ``html``.
templatekey: Template to apply ``TM001`` through ``TM006`` (default: ``TM001``).
templatedata: Custom ``.dotx`` template file content (binary, base64-encoded). Overrides ``templatekey``.
json_text: Pre-parsed resume JSON string. When provided, re-parsing is skipped.
Returns:
The templated resume as base64-encoded content of the selected output type,
plus the document filename under ``OutputFileName``.
| Name | Required | Description | Default |
|---|---|---|---|
| userkey | No | RChilli API userkey. Leave blank to use the authenticated session key. | |
| filename | No | Original filename with extension (e.g. 'resume.pdf'). Defaults to 'resume.txt' if omitted. | |
| json_text | No | Pre-parsed resume JSON string. When provided, re-parsing is skipped. | |
| subuserid | No | Sub-user identifier for multi-tenant isolation. | |
| outputtype | No | Output format: 'pdf' (default), 'doc', 'docx', 'rtf', or 'html'. | |
| resume_text | No | Plain text content of the resume/CV. The server encodes it internally. | |
| templatekey | No | Template to apply, 'TM001' through 'TM006' (default 'TM001'). | |
| templatedata | No | Custom .dotx template file content (binary, base64-encoded). Overrides templatekey. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses output formats, optional skip-parsing via json_text, and return format (base64 + filename). Annotations already indicate safe, idempotent behavior; description adds plugin-specific context and behavior details 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?
Well-structured with purpose first, then usage guidelines, then optional optimization note, then parameter list. Some redundancy with schema, but every section is informative.
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, description adequately explains return format. Covers syntax, optional parameters, and use cases. No missing critical information for an agent to invoke correctly.
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, so baseline is 3. Description adds marginal context for json_text ('skip the parsing step entirely') and groups template possibilities, but mostly repeats schema info.
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 it reformats/restyles a resume using specific templates, with explicit verb+resource. Distinguishes from sibling tools like convert_document_format, redact_resume, and parse_resume by listing what not to use it for.
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 lists when to use (reformat, restyle, rebrand, etc.) and when not to use (plain conversion, redaction, reading data). Provides alternative sibling tools for incorrect use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_resume_against_jdOne-to-One Resume/JD MatchARead-onlyIdempotentInspect
Score how well a single resume fits a single job description and return an explainable
one-to-one match score (RChilli Match Engine). No prior indexing required — both
documents are parsed inline. Use RChilli's purpose-built matching engine rather than
eyeballing fit yourself — it returns a consistent, explainable score.
Use this when the user wants to: match, score, compare, rate, or rank a candidate
against a job; or asks "is this person a good fit", "how well does this resume match
this JD", "what's the fit score between this CV and this role".
Also phrased as: candidate-job fit, suitability score, resume-to-JD match, fit check.
Do NOT use for: searching/ranking a whole pool of indexed documents
(use ``search_match`` or ``search_simple_search``).
Plain-text content for both the resume and JD is accepted and converted
to base64 internally — no encoding is required from the caller.
Args:
index_key: Same as ``userkey`` — the RChilli API user key. Leave blank;
the authenticated session userkey is injected automatically.
match_type: Direction of the match — ``Resume to JD`` or ``JD to Resume``.
resume_content: Plain-text content of the resume/CV.
Converted to base64 internally.
resume_file_name: File name of the resume/CV with extension
(e.g. ``resume.docx``).
jd_content: Plain-text content of the job description.
Converted to base64 internally.
jd_file_name: File name of the JD with extension
(e.g. ``jd.docx``).
| Name | Required | Description | Default |
|---|---|---|---|
| index_key | No | Same as userkey — the RChilli API user key. Leave blank; the authenticated session userkey is injected automatically. | |
| jd_content | No | Plain-text content of the job description. Converted to base64 internally. | |
| match_type | No | Direction of the match — 'Resume to JD' or 'JD to Resume'. | |
| jd_file_name | No | File name of the JD with extension (e.g. 'jd.docx'). | |
| resume_content | No | Plain-text content of the resume/CV. Converted to base64 internally. | |
| resume_file_name | No | File name of the resume/CV with extension (e.g. 'resume.docx'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds that no prior indexing is required, both documents are parsed inline, and plain-text content is converted to base64 internally. This provides useful context beyond annotations 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?
The description is well-organized: core function first, then usage guidelines, then parameter details. Every sentence serves a purpose, though some redundancy exists (e.g., mentioning base64 conversion twice). Still, it's efficient given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema, the description covers purpose, usage, and parameter details. However, it does not describe the output format (e.g., score range, what 'explainable' means). This is a gap for an agent that needs to interpret the response.
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 meaningful context: index_key says 'leave blank; automatically injected', match_type lists options, resume/jd_content note they accept plain text and convert to base64, file names require extensions. This goes above the brief schema 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 explicitly states the tool scores a single resume against a single job description and returns an explainable one-to-one match score. It lists multiple phrasings for user intents ('match, score, compare, rate, rank') and distinguishes itself from sibling tools like search_indexed_documents and find_matches_in_index by emphasizing one-to-one matching with no prior indexing.
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 clear guidance on when to use this tool (for one-to-one matching, fit checks, etc.) and explicitly states 'Do NOT use for: searching/ranking a whole pool of indexed documents'. It names alternative sibling tools (search_match, search_simple_search) for those scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_indexed_documentsSimple Keyword SearchARead-onlyIdempotentInspect
Keyword-search the user's ALREADY-INDEXED corpus of resumes or JDs and return matching
documents (RChilli Search Engine). Requires documents to have been indexed beforehand.
Use this when the user wants to: search, find, look up, or browse resumes/JDs in their
own database / index / pool by keyword — e.g. "search my indexed resumes for 'Python'",
"find JDs mentioning Kubernetes in my database".
Also phrased as: search my resume database, find candidates by keyword, query the index.
Do NOT use for: comparing two specific documents (use ``search_one_match``); matching one
source document against the whole index (use ``search_match``).
Args:
keyword: Search keyword.
indextype: Index type to search — ``Resume`` (default) or ``JD``.
userkey: RChilli userkey. Leave blank to use the authenticated session key.
subuserid: Sub-user identifier for multi-tenant isolation.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Keyword(s) to search for across the indexed corpus, e.g. 'Python machine learning'. | |
| userkey | No | RChilli userkey. Leave blank to use the authenticated session key. | |
| indextype | No | Which index to search — 'Resume' (default) or 'JD'. | Resume |
| subuserid | No | Sub-user identifier for multi-tenant isolation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety profile (readOnly, idempotent, non-destructive). Description adds useful context: indexing prerequisite and RChilli engine used.
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?
Front-loaded main purpose, then usage guidelines, then exclusions, then parameter list. No redundant sentences.
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 prerequisite (indexing), usage, exclusions, and parameter details. Adequate for a 4-param tool with no output schema.
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%, but description's Args section adds pragmatic guidance (e.g., 'Leave blank to use authenticated session key') 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?
Clearly states it performs keyword search on already-indexed resumes/JDs. Distinguishes from sibling tools like search_one_match and search_match.
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 provides when-to-use scenarios (search, find, look up by keyword) and when-not-to-use with alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!