Ashby

Look 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. ## 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.

describe_object_fields

Filter 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. In most cases, you should first call \`describe_object_fields\` to discover valid field paths, supported operators, and selectable/reference fields. Use the field paths returned by \`describe_object_fields\` exactly as shown. Use the value form that matches the field and tool behavior: - **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. - **Literal fields**: For normal string, number, boolean, or date fields, use the literal value in the appropriate format. ## Sorting Use \`sort\` with field paths from \`describe_object_fields\` for latest, earliest, highest, lowest, or alphabetical requests. ## Filter format examples - Field operators: \`{ "operator": "<op>", "field": "<field_path>", "value": <value> }\` - "equals": exact match (string, number, boolean, or selectable value label) - "contains", "starts", "ends": string matching - "greater", "less", "greaterOrEqual", "lessOrEqual": numeric comparison - "empty": checks if field is null/empty (no value needed) - "daterange": date range filter with \`{ "type": "Since"|"Before"|"Between"|"Previous", ... }\` - Logical operators: - \`{ "operator": "and", "filters": [...] }\` - \`{ "operator": "or", "filters": [...] }\` - \`{ "operator": "not", "filter": { ... } }\` **Example**: Find active applications for a job: \`\`\`json { "operator": "and", "filters": [ { "operator": "equals", "field": "job_id", "value": "<job_id>" }, { "operator": "equals", "field": "process_status", "value": "active" } ] } \`\`\` When a user asks about "my" candidates or applications, use the "involves" field with the user's name to filter down results to only those that involve the user. **Example**: Find applications involving the user "John Smith": \`\`\`json { "operator": "and", "filters": [ { "operator": "equals", "field": "involves", "value": "John Smith" } ] } \`\`\`

filter_records

Fetch 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. ## 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 list_applications and retry with the relevant applicationIds. ## 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_candidate

Get 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 \`get_upcoming_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_details

Get 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_interview_plan

Get 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_job_pipeline

Get 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_pending_tasks

Fetch detailed Ashby records by ID for jobs, job postings, applications, communication templates, openings, scheduled interviews, and offers. 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. 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.

get_record_details

Fetch 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\`, or \`get_candidate\` before calling this tool. Provide \`interviewEventId\` when the question is about feedback for a particular interview; interview event IDs can come from \`get_upcoming_interviews\`, \`get_pending_tasks\`, or \`get_interview_details\`. This only returns feedback submitted by the current user. It does not fetch other interviewers' feedback or edit feedback.

get_submitted_feedback

Get a paginated summary of the current Ashby user's upcoming interviews. Use this when the user asks about their upcoming interviews, interview schedule, interview briefings, or interviews within a date window. Provide ISO 8601 date-times with \`onOrAfterDate\` and \`onOrBeforeDate\` to constrain the window; if omitted, the tool defaults to the next 7 days. Use \`cursor\` from a previous response to continue pagination. The response includes interview event IDs, times, titles, candidate names, job titles, and briefing URLs. Use the returned \`interviewEventId\` with \`get_interview_details\` when the user needs the full briefing or candidate context for an interview.

get_upcoming_interviews