add_note_to_candidate
ChatGPTAdd a note to a candidate's profile.
Business & Operations
Overview
Ashby in ChatGPT gives you instant access to your pipeline, candidate profiles, open jobs, interviews, and transcripts. Ask questions, uncover hiring trends, and take action by adding notes, moving stages, or sending emails directly from the chat. Ashby connects ChatGPT to your live recruiting data through secure user-level OAuth. Every request and action respects your existing permissions and your data stays protected. Try prompts like these: “Summarize our current engineering pipeline, highlight bottlenecks, and identify at-risk candidates.” "Consider [Candidate Name] for our open Staff Engineer role and move them to the recruiter screen stage." “Generate a debrief summary for [Candidate Name] using interview feedback, scorecards, and recruiter notes.” “Analyze time-to-fill trends across sales roles and summarize where delays are occurring.”
Tools
change_application_stage
ChatGPTMove an application to a different interview stage. The \
stageId\ must be a stage in the application's own interview plan. Call \get_interview_plan\ with the applicationId first to list the plan's stages and their IDs, then pass the target stage's ID here. Before you move the application, always tell the user the names of the stages it is moving from and to.consider_candidate_for_job
ChatGPTCreate a new application for a candidate on a specific job. Optionally provide an \
interviewStageId\ to place the application at a specific stage. Call \get_interview_plan\ with the jobId first to discover available stage IDs. If omitted, the application starts at the first stage.create_candidate
ChatGPTCreate a new candidate record in Ashby with a name and optional contact information.
describe_object_fields
ChatGPTLook up filterable fields for a given object type. Returns field paths, valid operators, and selectable values. Use this before calling \
filter_records\ when you do not already know the correct field path. Always pass a searchTerm with 2-3 short, specific keywords for the fields you need (for example \"offer status"\ or \"hire date salary"\). Results are ranked by relevance. Use the returned field paths exactly as shown when constructing filters. Field paths are opaque API identifiers: if a path contains dots, the final segment is not valid by itself. For example, use \feedback_form.overall_recommendation\, not \overall_recommendation\. Search guidance - Use field discovery only when you do not already know the next field to try. - Search for the single next missing field, not for reassurance or alternate formulations. - If you already have one direct field for the current step, try using it before searching for additional alternatives. - Avoid broad keyword combinations when a narrower search can answer the next step.filter_records
ChatGPTFilter records of a given object type using a structured JSON filter. Supports result modes: "ids" (default), "count" (total count only), "summary" (IDs plus basic entity details). The
filter argument must always be a JSON-serialized object. Filters are capped at max depth 3, 8 predicates, 5 child filters per and/or group, and 2 sort fields. Use this tool after identifying the correct object type and field paths. For structured criteria, first call describe_object_fields unless you already have the exact field path from a prior tool result. Do not invent common field names such as title, name, application_id, or overall_recommendation unless that exact field path was returned for the selected object type. Use the value form that matches the field and tool behavior: - Field paths: Use the complete field path returned by describe_object_fields, including prefixes such as feedback_form., candidate., or interview.. Never shorten a returned field path to only the final segment. - Label-based selectable fields: For fields such as tags, statuses, users, teams, and similar selectable values, use the human-readable label where supported. The system automatically resolves labels to IDs for supported fields. - Reference fields: For many reference fields, including many fields named like *_id, the system may support either: - a resolved ID, or - a human-readable title/label. - Prefer IDs when available: If you already resolved the referenced entity and have its ID, prefer using the ID for reliability and disambiguation. - Score fields: Fields whose Value type is Score require numeric values: 4 = Strong Yes, 3 = Yes, 2 = No, 1 = Strong No, 0 = No score provided. Do not pass labels like "Strong Yes" to Score fields. - Literal fields: For normal string, number, boolean, or date fields, use the literal value in the appropriate format. - Follow the chosen field's Value type line from describe_object_fields. Do not infer the value form from the field name alone. - Filter errors: If an error says "Did you mean", retry once with one of the suggested complete field paths before changing tools or object types. Sorting Use sort with field paths from describe_object_fields for latest, earliest, highest, lowest, or alphabetical requests. Filter format examples Every filter is one object with a top-level \"operator"\ — put the operator in the \"operator"\ key, never as a key nested under the field. - Field operators — \{ "operator": "<op>", "field": "<field_path>", "value": <value> }\: - "equals": \{ "operator": "equals", "field": "status", "value": "Active" }\ - "similarTo" (fuzzy text match — the default for free-text like names, schools, companies; tolerates typos): \{ "operator": "similarTo", "field": "name", "value": "john" }\ - "contains" / "starts" / "ends" (literal string matching; use "contains" only when the user explicitly asks for exact substring containment): \{ "operator": "contains", "field": "name", "value": "john" }\ - "greater" / "less" / "greaterOrEqual" / "lessOrEqual" (numbers only): \{ "operator": "greaterOrEqual", "field": "years_of_experience", "value": 2 }\ - "empty" (no value): \{ "operator": "empty", "field": "primary_personal_email_address" }\ - "daterange": \{ "operator": "daterange", "field": "created_at", "value": { ... } }\ — see Date range filters below. - Logical operators: - \{ "operator": "and", "filters": [<filter>, ...] }\ - \{ "operator": "or", "filters": [<filter>, ...] }\ - \{ "operator": "not", "filter": <filter> }\ Do not nest the operator under the field: \{ "name": { "contains": "peter" } }\ is wrong. Always use the flat operator/field/value shape shown above. Example: Find active applications for a job: ``json { "operator": "and", "filters": [ { "operator": "equals", "field": "job_id", "value": "<job_id>" }, { "operator": "equals", "field": "status", "value": "Active" } ] } ` **Date range filters** — for \"operator": "daterange"\, \value\ is one of these shapes (dates are \YYYY-MM-DD\` strings; …get_candidate
ChatGPTFetch details about one or more candidates. Choosing sections - For a candidate summary, omit the
sections parameter. - Request only the sections relevant to the user's question. - For questions about whether a candidate mentioned, shared, or said something, start with emails and interviewFeedback, then fetch other relevant communication/context sections before saying the information was not found. - For all interview feedback visible to the current user, pass sections: ["interviewFeedback"]. Use get_submitted_feedback when the user specifically asks for their own feedback. Application scoping When applicationIds is not provided, this tool returns data based on the candidate's most recent applications, prioritizing non-archived applications. For role-specific questions, call filter_records with objectType: "application" filtered to the candidate, then retry with the relevant applicationIds. Source and credited-to Basic candidate info reports the candidate's own source and credited-to in <CandidateAttribution>. These are candidate-level values; do not report them as application-level attribution. Interview transcripts The interviewTranscripts section returns metadata only (transcript ID, interview title, timestamp, interviewers) without the full transcript text. To read the full transcript, call get_record_details with entityType: "transcript" and entityIds containing the transcript ID from the identifier attribute. Pagination Each section returns metadata indicating if more items are available. Use offset and limit to paginate: - offset: Number of items to skip (default: 0) - limit: Maximum items to return per section (default: 5, maximum: 10)get_interview_details
ChatGPTGet a detailed interview briefing for a specific Ashby interview event. Use this when the user asks for briefing context for an upcoming or pending interview, such as who is interviewing, candidate background, resume summary, candidate/job custom fields, candidate source, or interview instructions. The required \
interviewEventId\ comes from \list_interviews\, \get_pending_tasks\, or the \interviewEventId\ field returned by \get_record_details\ for an interview record. Set \includeInstructions\ to true only when the user needs interview instructions. The response is read-only briefing data and includes candidate/job context, hiring team members, co-interviewers, resume summary, custom fields, and links back to Ashby.get_interview_plan
ChatGPTGet the interview plan and its stages for an Ashby application or job. Provide either an applicationId or a jobId (at least one is required). If applicationId is provided, returns the interview plan for that specific application. If jobId is provided, returns the default interview plan for that job
get_job_pipeline
ChatGPTGet pipeline metrics for one or more Ashby jobs, including per-stage application counts. Use this when the user asks how many candidates or applications are in a job's pipeline, how candidates are distributed across interview stages, or for a pipeline overview. First resolve job IDs with \
search_records_by_name\ for a simple job-name lookup or \filter_records\ for structured criteria, then pass those IDs here. Batch multiple job IDs in one call when comparing pipelines. The response groups jobs that share an interview plan and returns job summaries, interview plan stages, and per-job counts for each stage. Use \get_interview_plan\ instead when the user needs the stage structure without counts.get_pending_tasks
ChatGPTGet the current Ashby user's pending homepage tasks. Use this when the user asks what they need to do, what tasks are pending, which scorecards or approvals they owe, or for their pending sequence, survey, mention, follow-up, text, or candidate review tasks. Call with no arguments to fetch all task categories, or pass \
taskTypes\ to narrow the response. The response groups tasks by category and includes relevant Ashby entity IDs, names, URLs, and interview event IDs when applicable. Use returned candidate IDs with \get_candidate\ and returned interview event IDs with \get_interview_details\ when the user asks for more context.get_record_details
ChatGPTFetch detailed Ashby records by ID for any of the record types listed in the
entityType enum. Use this after search_records_by_name or filter_records returns the IDs of the records the user asked about. Pass up to 10 IDs in one call. This tool is for hydrating records that have already been identified; it does not search by name or filter criteria. Every entityType except transcript and communication_template corresponds to the filter_records object type of the same name, so those IDs can be passed through unchanged. For candidate profile details, use get_candidate instead. For interview records, pass scheduled interview IDs returned by filter_records; the response includes interviewEventId, which can be passed to get_interview_details for the full briefing. For transcripts, pass the meeting recording ID returned by filter_records with the meeting_recording object type; the response includes the full transcript text with speaker names and timestamps, plus interview metadata when available. For employees, pass the employee IDs returned by filter_records; the response includes name, email, job title, start date, and manager. Transcripts are large, so only up to 1 transcript IDs are allowed per call, even though other entity types allow up to 10. interview_schedule and interview are different records. An interview_schedule is the scheduling workflow for one interview stage of an application — its status, timezones, and whether availability was requested or provided. An interview is a single scheduled event with a time and interviewers. Use interview_schedule for questions about scheduling progress, and interview for questions about a specific meeting. An interview_schedule response lists its events under scheduledEvents, whose id can be passed back as an interview entity ID.get_submitted_feedback
ChatGPTFetch the current Ashby user's submitted scorecard feedback for an application. Use this when the user asks what feedback they already submitted, wants to review their own scorecard, or asks for their submitted feedback for a specific interview. Resolve the \
applicationId\ with \search_records_by_name\, \filter_records\, \get_candidate\, or \list_interviews\ before calling this tool. Provide \interviewEventId\ when the question is about feedback for a particular interview; interview event IDs can come from \list_interviews\, \get_pending_tasks\, or \get_interview_details\. This only returns feedback submitted by the current user. If the user asks for all feedback or feedback from other interviewers, use \get_candidate\ with \sections: ["interviewFeedback"]\ instead.list_interviews
ChatGPTSearch the current Ashby user's interviews by candidate name and/or date range. Use this when the user asks about their interviews, interview schedule, or mentions a candidate by name. The window defaults to the past 7 days through the next 7 days, so both recent and upcoming interviews are included. Pass \
onOrAfterDate\/\onOrBeforeDate\ to search other periods. Use the returned interviewEventId with \get_interview_details\ or the returned applicationId with \get_submitted_feedback\.search_records_by_name
ChatGPTSearch across candidates, jobs, applications, and communication templates in Ashby. Resolves a name to its canonical record ID. Use this for simple name lookups; use \
filter_records\ for structured criteria.submit_mcp_feedback
ChatGPTSubmit product feedback about the Ashby MCP server and its tools to the Ashby team. Call this when the user explicitly reports an MCP issue, limitation, or suggestion, or when you cannot complete the user's Ashby task because the available MCP tools are missing a needed capability, returned confusing/incomplete results, or produced an error that blocked the task. In the feedback, include the user's goal, the Ashby MCP tool(s) or workflow you tried, what went wrong or was missing, and the tool/capability/result that would have helped. This tool sends feedback to Ashby; it does not create, modify, or delete any Ashby records. Feedback longer than 5000 characters is truncated.
add_note_to_candidate
Claudechange_application_stage
Claudeconsider_candidate_for_job
Claudecreate_candidate
Claudedescribe_object_fields
Claudefilter_records
Claudeget_candidate
Claudeget_interview_details
Claudeget_interview_plan
Claudeget_job_pipeline
Claudeget_pending_tasks
Claudeget_record_details
Claudeget_submitted_feedback
Claudeget_upcoming_interviews
Claudesearch_product_docs
Claudesearch_records_by_name
ClaudeCapabilities
Writes
Links
App Stats
32
Tools
ChatGPT, Claude
Platforms
Category
Hiring WorkflowWorks with
ChatGPT
Claude
Data refreshed daily