Metaview

<usecase> Generate (or regenerate) AI Notes for a conversation, optionally with a specific built-in or custom template — including to preview how a newly created or updated template renders on a real conversation. Regenerating creates a new version of the conversation's notes; prior versions are preserved and the user can revert in the Metaview web app. </usecase> <instructions>Generation is asynchronous (~30 seconds). After calling, wait ~30s then poll search_conversations(conversation_ids=[...], fields=["default:summary"]) yourself — do not ask the user.</instructions> <response_format>{"status": "generation_queued"}</response_format>

generate_notes

<usecase>Read a reusable Job Post template with its full structured content and section instructions.</usecase> <instructions>Use list_job_post_templates to find templates. Copy built-ins to edit them.</instructions> <data_model>See list_job_posts for the Job Posts data model.</data_model>

get_job_post_template

<usecase> Get the full state of one Application Review: the ACTIVE ICP, any pending DRAFT edit, the RANKING version if a rerank is running, version history, a decision summary, and the fit-band distribution of the current ranking. Read this before refining an ICP: it shows what the review scores against and whether an edit or rerank is already in flight. Pair with list_application_review_candidates for individual ranked applicants. </usecase> <instructions> Pick restore targets for restore_application_review_icp from version_history. missing_ats_setup_fields is non-empty only when decisions will be refused and no argument can prevent it — the user must configure the named fields in the web app; do not attempt the decision. pending_admission_count = matched, not admitted; pending_evaluation_count = admitted, not yet scored. decisions and fit_distribution count admitted candidates for the ACTIVE version. </instructions> <response_format> Full (default): {"application_review_id", "job_title", "run_state", "active_icp"?: {"version", "text", "activated_at", "activated_by"}, "pending_draft"?, "ranking_version"?, "requested_version"?, "version_history": [{"version", "lifecycle_state", "change_source", "reasoning", "activated_at"}], "rerank_status": "complete"|"in_progress", "decisions": {by decision}, "pending_admission_count", "pending_evaluation_count", "fit_distribution", "missing_ats_setup_fields", "next", "applicant_source"?: "UPLOAD"} Concise: {"application_review_id", "run_state", "active_version", "ranking_version", "rerank_status", "rerank_in_flight", "pending_admission_count", "pending_evaluation_count", "missing_ats_setup_fields", "next", "applicant_source"?: "UPLOAD"} </response_format> <data_model>See list_application_reviews for the Application Review data model.</data_model>

get_application_review_details

<usecase> Read the workspace-wide Application Review evaluation rules — a single standing instruction the review agent applies when constructing and refining the ICP for every review in the workspace (e.g. company-wide disqualifiers, visa policies, location constraints). Per-review criteria live on the review's ICP instead — see get_application_review_details. </usecase> <instructions>rules is null when the workspace has not set any. To change the rules use update_application_review_rules.</instructions> <response_format>{"rules": "text or null"}</response_format> <data_model>See list_application_reviews for the Application Review data model.</data_model>

get_application_review_rules

<usecase>Read a Job Post's creator, document, check results and agent progress.</usecase> <instructions>Editable posts return live document text, agent status and a page of chat messages. View-only shares and posts whose agent is unavailable return the latest saved projection, which can lag live edits, with no live status. When status is running or provisioning, poll again in 10-30 seconds. An idle or dormant agent may be waiting for an answer; read its latest message. Use send_job_post_message to respond and list_job_post_threads for suggestions. Returns the newest run per visible check (up to 100), with verdict, completion and outdated flags. For current failures, count posts with a failed, non-outdated run. If check_runs_truncated is true and no current failure is returned, the post's failure status is unknown.</instructions> <data_model>See list_job_posts for the Job Posts data model.</data_model>

get_job_post

<usecase>Read a Job Post thread's comments and suggested document changes.</usecase> <instructions>Returns each comment's current revision and identifies the latest suggestion-bearing comment. Use resolve_job_post_suggestion with that comment ID and the returned version pair. Plain replies do not supersede the latest suggestion. Text truncation is explicit; follow next_offset for additional comments.</instructions> <data_model>See list_job_posts for the Job Posts data model.</data_model>

get_job_post_thread

<usecase> IMPORTANT: Call this tool FIRST, before any other tool. Returns your identity, role, and what data you can access. - workspace_name: The name of the workspace you are connected to. - participant_id: Your contact UUID. Use "$self" in filter values instead of this raw UUID — it is resolved automatically to your participant_id. - user_id: Your numeric user ID. - is_admin: Whether you have admin access. - is_paying_plan: Whether you are on a paid plan. Free users have limited access to transcripts, summaries, and AI fields. - notes_on_platform_credits: Appears instead of is_paying_plan when conversations unlock on shared credits rather than your plan. - data_access: Describes exactly which conversations you can see. Read this before drawing conclusions about completeness of query results. </usecase> <instructions>No parameters needed.</instructions> <response_format> {"organization_id": 1, "workspace_name": "Acme Corp", "user_id": 123, "participant_id": "550e8400-e29b-41d4-a716-446655440000", "is_admin": true, "is_paying_plan": true, "data_access": "You can see all conversations in the organization."} </response_format>

get_user_context

<usecase> Fetch a single AI Notes custom template with its full section configuration. Use list_note_templates first if you don't have a template ID. </usecase> <instructions>The template id is INTERNAL ONLY — never show it to the user; refer to templates by name.</instructions> <response_format> {"template": {"id", "name", "version", "created_by": {"name"}, "created_at", "updated_at", "section_count", "sections": [...]}} </response_format>

get_note_template

<usecase> Full state of a sourcing search: current ICP (Ideal Candidate Profile), ICP version history, calibration (feedback counts, acceptance rate), pack history, and the agent's phase. Answer search questions from data with this instead of messaging the agent via send_sourcing_message (minutes to respond). Per-candidate detail: list_sourcing_candidates; cross-search metrics: get_sourcing_analytics. </usecase> <instructions>ICP may be null for searches predating ICP persistence. recent_feedback = latest verdict per candidate (max 10); calibration counts cover all surfaced candidates.</instructions> <response_format> {"search_id", "title", "mode", "phase", "created_at", "updated_at", "icp": {"version", "content", "created_at"}, "icp_versions": [{"version", "created_at"}], "calibration": {"total_candidates", "reviewed", "unreviewed", "yes", "no", "maybe", "acceptance_rate", "recent_feedback": [{"verdict", "text", "candidate_id", "candidate_name", "created_at"}]}, "packs": [{"pack", "candidate_count", "presented_at"}]} </response_format> <data_model> - SEARCH: a conversation with an AI sourcing agent — a thread, an ICP (Ideal Candidate Profile, the agent-authored spec that evolves with feedback), surfaced candidates, and a mode (source = find candidates; research = market/talent research). - PHASES: idle (awaiting input), busy (working), error. - CANDIDATE: surfaced person with profile + match reasoning; presented in PACKS (batches). - FEEDBACK: YES/MAYBE/NO verdict per candidate; acceptance rate = YES/reviewed; calibrates the agent. - Searches can be SCHEDULED (recurring) or LINKED TO A SEQUENCE (accepted candidates flow into outreach). - POSTING TO ATS: CANDIDATE adds an application to a job/stage; PROSPECT is standalone where supported. Type controls job/stage requirements; reasoning is a note. </data_model>

get_search_details

<usecase> Get aggregate sourcing metrics for your workspace with flexible filtering and grouping — search/candidate/feedback counts, acceptance rates (overall, per user, or per search), weekly or monthly activity trends, scheduled or sequence-linked search counts, and seat utilization. For one search's own state use get_search_details; for its candidates use list_sourcing_candidates. </usecase> <instructions> Permissions: non-admins always see only their own data (user_id is ignored); admins see the whole workspace and may filter with user_id. seat_utilization is admin-only. For comparisons (e.g. this month vs last month), call twice with different time_period values. </instructions> <response_format>{"metric", "value"? (ungrouped), "groups"?: [{"label", "id", "value", "count"}], "total_groups"?, "has_more"?, "time_range"?: {"start", "end"}, "filters_applied"?}</response_format> <data_model>See get_search_details for the sourcing data model definitions (searches, agent phases, candidates, feedback, ICPs, scheduled searches, search-sequence links, posting to ATS).</data_model>

get_sourcing_analytics

<usecase> Retrieve the conversation history for a sourcing search — messages between you and the agent, with structured attachments (candidates, ICP, calibration, file, filter_proposal) rendered as separate messages. Poll this after sending a message. The phase field indicates progress: busy = agent still working (poll again shortly); idle = agent finished or awaiting your input; error = something went wrong. Candidate attachments only show IDs — get full details with list_sourcing_candidates or fetch_candidates. </usecase> <instructions>While phase is 'busy', poll again in 10-30 seconds. Messages are ordered chronologically.</instructions> <response_format>{"search_id", "phase", "messages": [{"role", "content", "timestamp", "message_type"}], "total_count", "has_more", "next"}</response_format> <access_scope>Results are scoped server-side to data the authenticated user can already access in Metaview, within their workspace and role.</access_scope>

get_sourcing_messages

<usecase> Record a REJECT or PROGRESS decision on one or more admitted candidates in an Application Review, optionally with free-text feedback. IMPORTANT: this is a live decision, not a draft. Decisions sync to the customer's connected ATS — a REJECT can move the candidate's ATS stage and send a rejection email; a PROGRESS can advance their ATS stage. These effects are visible to the hiring team and, for rejection emails, to the candidate. Reviews with applicant_source UPLOAD have no ATS: their decisions are saved in Metaview only. Only call this tool with decisions the user has confirmed. </usecase> <instructions>Before a REJECT (unless applicant_source is UPLOAD), call list_application_review_rejection_options: it reports which rejection fields the review's ATS requires and the valid reason / email template ids to pass. A REJECT missing an ATS-required field is refused. Rejection fields are ignored on a PROGRESS.</instructions> <response_format>{"application_review_id", "decision", "candidate_count", "updated_candidate_ids"}</response_format> <data_model>See list_application_reviews for the Application Review data model.</data_model>

give_application_review_candidate_feedback

<usecase> Submit YES/MAYBE/NO feedback on one or more candidates in a sourcing search. Feedback calibrates the sourcing agent — accepting or rejecting candidates helps it refine its search and find better matches. IMPORTANT: The agent does NOT automatically act on feedback. To have it refine the search, set request_refinement=true on your FINAL feedback batch, or send a custom instruction with send_sourcing_message. </usecase> <instructions>Get candidate IDs from list_sourcing_candidates. Verdict meanings — YES: strong match, move forward; MAYBE: possible match, keep in consideration; NO: not a match. Failures are per-item: check each result's success flag.</instructions> <response_format>{"search_id", "results": [{"candidate_id", "success", "error"?}], "refinement_triggered"?, "next"}</response_format> <examples>give_sourcing_feedback(search_id="550e8400-...", feedbacks=[{"candidate_id": "c1a2b3d4", "accepted": "YES"}, {"candidate_id": "d4e5f6a7", "accepted": "NO", "text": "Too junior"}], request_refinement=True)</examples>

give_sourcing_feedback

<usecase> Group conversations by a field and compute per-group counts and metrics. Prefer this tool for 'how many', breakdowns, distributions, rankings, and 'by X' questions; time-series trends → get_chart_data; individual rows → search_conversations. POWERFUL PATTERN for finding trends across many conversations: 1. Create an AI field (create_ai_field) extracting the data point of interest. 2. Group by that AI field to see its value distribution, or group by another field (e.g. interviewer) with the AI field as a metric. This avoids reading raw transcripts and works at any scale. </usecase> <instructions>Find groupable field IDs (groupable=true) and metric IDs with list_fields; look up filter values with list_field_values.</instructions> <response_format> {"groups": [{"label", "value", "conversation_count", "metric_values"?: {"<metric_id>:<function>": 156.0}}], "total_groups", "total_conversation_count", "has_more", "ai_processing"?: {"AI:<uuid>": {"pending_count", "total_count"}}} </response_format> <notes> Note: AI field values are computed asynchronously — if "ai_processing" is present in the response, poll by retrying the same call every ~30 seconds. Always apply tight filters before using AI fields. See search_conversations for the full AI field evaluation guidance. IMPORTANT: while ai_processing is present, counts are incomplete — grouping by an AI field can make the groups' conversation_count sum to LESS than total_conversation_count, and filtering by an AI field excludes not-yet-evaluated conversations (lowering total_conversation_count). Wait for pending_count to reach 0 before treating counts as complete. </notes>

group_conversations

<usecase> List active jobs in the workspace's connected ATS (Applicant Tracking System). Use this to find the ATS job to post sourcing candidates to with post_sourcing_candidates_to_ats, discover available posting types, and check job_required and posting_disabled_reason before posting. </usecase> <instructions>If the user selects a posting_type, use it consistently when listing jobs, listing stages, and posting. Otherwise omit it to use the workspace default. If posting_disabled_reason is non-null, relay the reason to the user. If job_required=false, post without a job or stage.</instructions> <response_format>{"jobs": [{"id", "title", "department", "location"}], "has_more", "posting_types", "job_required", "posting_disabled_reason", "next"}</response_format>

list_ats_jobs

<usecase> List the application stages for a job in the workspace's connected ATS. Use this to find the stage_id to post sourcing candidates into with post_sourcing_candidates_to_ats. Providing a stage is optional — when omitted, candidates land in the ATS default stage for the job. </usecase> <instructions>Get job IDs and posting types with list_ats_jobs; reuse that posting_type when posting.</instructions> <response_format>{"job_id", "stages": [{"id", "name"}], "next"}</response_format>

list_ats_stages

<usecase>Discover reusable Job Post templates, including workspace and built-in templates.</usecase> <instructions>Returns compact summaries. Use get_job_post_template for full content, then upsert_job_post_template to create or replace a workspace template. Follow next_offset while has_more is true. </instructions> <data_model>See list_job_posts for the Job Posts data model.</data_model>

list_job_post_templates

<usecase> List the review's ADMITTED (ranked) roster, ranked against the ACTIVE ICP. Applicants matched but not yet admitted are excluded and reported as pending_admission_count; admitted but unscored candidates are pending_evaluation_count. This is the feedback half of ICP refinement: after an ICP update reranks the review, use this to verify the bar moved the way you intended. IMPORTANT: fit is a coarse band only (great / good / okay / no_evidence / poor). Numeric scores and ordinal rank positions are never exposed, and the list is never ordered by internal score — it is ordered by fit band, then application date. For a candidate's full profile, resume, or ATS application detail, call fetch_candidates with the candidate_id and this application_review_id — this tool owns only what the review knows. </usecase> <instructions> Only completed rankings are served: while a full rerank is in flight (a RANKING version exists) this returns an error — poll get_application_review_details until the new version is ACTIVE. During routine incremental evaluation of new applicants the stable ACTIVE ranking is served, with pending_evaluation_count noting how many are not yet scored. The response echoes active_version — the ACTIVE ICP display version the returned fit bands were computed against (null when the review has no active ranking yet). </instructions> <response_format>{"application_review_id", "active_version", "candidates": [{"candidate_id", "name", "overall_fit", "decision", "applied_at", "decided_at"?, "decision_feedback"?, "reasoning"?, "ai_columns"?: [{"column", "type"?, "value"?, "fit"?, "reasoning"?}]}], "total_count", "has_more", "pending_admission_count", "pending_evaluation_count", "next"}</response_format> <data_model>See list_application_reviews for the Application Review data model.</data_model>

list_application_review_candidates

<usecase> List the Application Reviews you can access, with run state, ICP version and roster counts. Find a review to inspect or refine here, then get_application_review_details for its ICP and version history, or list_application_review_candidates for the ranked applicants. </usecase> <instructions> Access: ATS hiring-team membership, admin, explicit share, or all-member access. rerank_in_flight: a full rerank is running; list_application_review_candidates declines partial results — poll get_application_review_details until it clears. </instructions> <response_format>{"reviews": [{"id", "job_title", "ats_job_ids", "run_state", "active_version"?: {"version", "lifecycle_state", "activated_at"}, "has_pending_draft", "rerank_in_flight", "admitted_count", "pending_count", "created_at", "updated_at", "applicant_source"?: "UPLOAD"}], "total_count", "has_more"}</response_format> <data_model> - A REVIEW ranks a job's inbound applicants (from the ATS, or uploaded CVs when applicant_source is UPLOAD) against an ICP (Ideal Candidate Profile). - ICP versions: DRAFT (proposed, not applied) -> RANKING (approved, full rerank in flight) -> ACTIVE (live) -> ARCHIVED. Version numbers are web-app display numbers (approved versions 1..N, oldest first); a pending DRAFT is unnumbered. - An ICP edit triggers a FULL RERANK of every admitted candidate (free but heavyweight); a RESTORE mints a NEW version from an ARCHIVED one, reusing prior evaluations (fast). - ADMISSION: ADMITTED (ranked roster; one credit at admission) or PENDING (a count, never rows). - FIT: coarse band only (great/good/okay/no_evidence/poor); numeric scores and rank positions never exposed. FRAUD RISK (LOW/MEDIUM/HIGH) is advisory, full detail only. - DECISION: PROGRESSED / REJECTED / null (undecided); syncs to the ATS (stage moves, rejection emails), except on UPLOAD reviews (saved in Metaview only). </data_model>

list_application_reviews

<usecase> Discover the fields and metrics for reports queries — call this first for analytics tasks. Returns FIELDS (IDs like 'default:start_time', 'OSPT:<uuid>', 'AI:<uuid>') for filters, group_by, columns, chart group; and METRICS ('aggregation:...') ONLY for metric_id in group_conversations and chart_inputs in get_chart_data. Never mix the ID kinds. The response's filter_formats map (operations + value format per field type) is the filter grammar for search_conversations, group_conversations, get_chart_data, create_report. </usecase> <instructions> Prefer search_term over fetching all. Ranked: exact and substring/regex first, then closest fuzzy matches (match='fuzzy'); field_ids does exact lookups. Only metrics with 'scatter' in chart_types support scatter plots (omit function/interval in get_chart_data). Use a metric's 'unit' when presenting values. </instructions> <response_format> {"fields": [{"id", "name", "type", "filterable", "groupable", "displayable", "filter_value_type", "description"?, "match"?, "filter_format"?}], "filter_formats": {"<type>": {"operations", "value_format"}}, "metrics": [{"id", "name", "unit"?, "functions", "chart_types", "chart_functions", "required_arguments"?, "match"?}], "total_field_count", "has_more"} </response_format> <data_model> - CONVERSATION: one recorded call. Unrecorded ones are excluded unless only_show_recorded_conversations=false. - CONTACT: a person on a call (UUID), NOT unique per person. Prefer default:interviewer (employees) or default:candidate. - FIELD: a conversation property. AI FIELDS ('AI:' prefix; 'AI Columns' in the app) hold AI-extracted per-conversation data. - default:transcript is large (at most ~5 conversations per request); default:summary generates on demand (slow, max 100/request). Free plan gates both. - "$self" as a person/participant filter value = the authenticated user. </data_model>

list_fields

<usecase> List candidates enrolled in a sequence, or get one candidate's full journey (pass candidate_sequence_id). Non-admins can only access sequences they created. Default is a summary row per candidate; include_detail adds per-step delivery status, include_messages adds the actual email content. Get sequence IDs from list_sequences; use manage_candidate_sequence to change enrollments. </usecase> <instructions>include_detail is required to obtain the candidate_sequence_step_id values needed for per-candidate updates via manage_candidate_sequence. WHATSAPP_BOUNCED means WhatsApp rejected the recipient as unreachable; the affected step has bounced_at and the enrollment is paused.</instructions> <response_format> {"sequence_id", "sequence_name", "candidates": [{"candidate_sequence_id", "candidate_id", "candidate_name", "candidate_email", "candidate_phone", "to_email", "to_phone_number", "status", "paused_reason", "cancelled_reason", "outcome", "created_by": {"name"}, "created_at", "steps_sent", "steps_total", "last_sent_at", "has_reply", "steps"? [{"candidate_sequence_step_id", "step_id", "position", "channel_type", "queued_for", "sent_at", "delivered_at", "opened_at", "replied_at", "bounced_at", "skipped_at", "subject", ...}], "messages"? [{...}]}], "total_count", "has_more"} </response_format>

list_sequence_candidates

<usecase> Get the possible values of one field — e.g. all departments, interviewer names, or job titles. Essential for looking up the person/participant IDs that PERSON- and PARTICIPANT-type filters require. Prefer search_term when looking for a specific value; results can also be scoped to a report or filter set so only values appearing in matching conversations are returned. </usecase> <instructions> Contact lookup — the same person can have MULTIPLE contact records. To avoid duplicates: interviewers/employees → field_id='default:interviewer'; candidates → 'default:candidate'; unknown role → 'default:contact' (may return several records per person; check is_internal). search_term supports substring matching and regex (auto-detected when the term contains regex characters). Prefer first and last name together; disambiguate before proceeding when several results return. Filter value formats are data, not prose: list_fields returns a filter_formats map (operations + value_format per field type; a field's type key selects its entry). IMPORTANT: date filter values are a dict, not a bare date string. Example: {"field_id": "default:start_time", "operation": "after", "value": {"scope": "relative", "value": -2592000}} </instructions> <response_format> {"field_id", "values": [{"value" (string, or int person ID, or UUID contact ID), "label", "person"? ({first_name, last_name, email, is_internal? — participant fields only})}], "has_more"} </response_format>

list_field_values

<usecase>Discover Job Posts check definitions and their complete judging instructions.</usecase> <instructions>Lists the effective workspace checks, including visible Metaview defaults and workspace overrides. Pass job_post_id to exclude checks hidden on that post. Use run_job_post_checks to execute selected checks and get_job_post to read their latest results. Follow next_offset for additional definitions.</instructions> <data_model>See list_job_posts for the Job Posts data model.</data_model>

list_job_post_checks

<usecase>Find open comment threads and suggestions on a Job Post.</usecase> <instructions>Use get_job_post_thread to read a thread's comments and proposed changes. Live documents are preferred; saved_projection can lag live edits. Resolved or deleted threads are absent; absence alone does not establish their outcome. Follow next_offset for additional threads.</instructions> <data_model>See list_job_posts for the Job Posts data model.</data_model>

list_job_post_threads

<usecase>Find accessible, active Job Posts by title or creator before reading or refining one.</usecase> <instructions>Returns creator identity for each post. Follow pagination to list all matching posts. Use get_job_post for document text, latest visible check verdicts and agent progress; list_job_post_templates for reusable templates; send_job_post_message to start or refine a draft.</instructions> <data_model>Job Posts are collaboratively drafted job descriptions, separate from ATS job records. created_by identifies the original creator by user_id and name when they belong to your workspace; null means the creator is unknown or outside your workspace. A reusable template defines ordered sections: static sections keep approved copy verbatim; generated sections use instructions and optional base copy. Workspace templates are shared with workspace members; built-in templates are read-only. The Job Posts agent drafts and refines a post asynchronously using its template and workspace reference documents. Comment threads hold discussion and proposed changes. Accepting or rejecting the current suggestion resolves its whole thread. Earlier suggestions in that thread are superseded. Checks are reusable workspace rules or Metaview defaults that judge a post against instructions. Workspace overrides replace their default.</data_model>

list_job_posts

<usecase> List the email mailboxes you can send sequence emails from. Returns your own active mailboxes plus any mailboxes where you have send-on-behalf-of permission. Use the mailbox id as from_mailbox_id when creating EMAIL steps in a sequence. </usecase> <instructions>No parameters needed.</instructions> <response_format> {"mailboxes": [ {"id": "abc-123", "email_address": "alice@acme.com", "person_id": 123, "person_name": "Alice Smith", "is_default": true, "is_owned_by_me": true}]} </response_format>

list_mailboxes

<usecase> List the folders (template groups) the caller can access. Use this when the user wants to move a template into a named folder — call list_note_template_groups first to resolve the folder name, then pass it to manage_note_template(action='update', group_name='...'). Templates not in a folder live in the caller's personal folder. </usecase> <instructions>Args: (none)</instructions> <response_format> {"groups": [ {"id": "...", "name": "Engineering", "template_count": 4}, {"id": "...", "name": "Recruiter", "template_count": 7}]} The `id` field is INTERNAL ONLY — never show it to the user. Refer to folders by name. </response_format>

list_note_template_groups

<usecase> List AI Notes custom templates the caller can access. Returns a lightweight summary per template. Pass include_detail=true or call get_note_template for the full sections. Use manage_note_template to create/update/delete templates. </usecase> <instructions>Template ids in the response are INTERNAL ONLY — keep them for subsequent tool calls but never show them to the user; refer to templates by name.</instructions> <response_format> {"templates": [{"id", "name", "version", "created_by": {"name"}, "created_at", "updated_at", "section_count", "sections"? (include_detail)}], "total_count", "has_more"} </response_format> <data_model> - A NOTE TEMPLATE (AI Notes custom template) defines the structure of AI-generated interview notes: a name plus an ordered list of sections. Template and group ids are internal — never show them to the user; refer to both by name. - A SECTION is one named block in the notes: a directive (SINGLE = one block under a fixed heading; REPEATING = one block per detected entity), a description (the instruction the LLM follows — the most important field), and an output type (TEXT, NUMBER, OPTIONS, or DATE). - A TEMPLATE GROUP (folder) can be private, shared with specific people, or workspace-shared; templates default to the caller's personal folder. - A SOURCE feeds notes generation: a conversation (type=session) or a plain-text document (type=document, e.g. a resume). Notes always have an anchor conversation; manage extra sources via manage_notes_sources. </data_model>

list_note_templates

<usecase> List the rejection options for an Application Review's connected ATS: which rejection fields a REJECT requires, the valid rejection reason ids, and the valid rejection email template ids. Call this before a REJECT via give_application_review_candidate_feedback so the decision carries every field the ATS requires and only valid ids. </usecase> <instructions> reject_requirements: per rejection field, REQUIRED (a REJECT must carry an effective value), OPTIONAL, or HIDDEN (the ATS has no such concept — do not pass the field). configured_defaults: values the review already stores; a REQUIRED field with a configured default is satisfied without passing it per decision. rejection_reasons / rejection_email_templates: the valid ids to pass, with display names; empty for HIDDEN fields. When the response says no rejection fields apply, REJECT decisions need no extra fields for this review. </instructions> <response_format>{"application_review_id", "reject_requirements": {"rejection_reason_id", "rejection_email_template_id"}, "configured_defaults": {"rejection_reason_id", "rejection_email_template_id"}, "rejection_reasons": [{"id", "name", "category"}], "rejection_email_templates": [{"id", "title"}], "applicant_source"?: "UPLOAD"}</response_format> <data_model>See list_application_reviews for the Application Review data model.</data_model>

list_application_review_rejection_options

<usecase> List the candidates on one screen with their stage, interview outcome, and decision — who has not been invited yet, who is invited but not interviewed, who is interviewed and waiting on a human, and who was progressed or rejected. Filter to stage='screened' for the review queue, then get_screen_interview to read the scorecard behind a candidate's fit. For a candidate's full profile, resume, or ATS application detail, call fetch_candidates with the candidate_id and this screen_id — this tool owns only what the screen knows. </usecase> <instructions> Order is best-fit first (great, good, okay, no_evidence, poor). Unscored candidates rank in the no_evidence band; tell them apart by overall_fit, which reads "no_evidence" for a scored candidate and null for an unscored one. Every field describes the candidate's most recent interview. overall_fit and bluf are null until it has been scored (not interviewed, still IN_PROGRESS / EVALUATING, or sent back for re-scoring by a published plan edit) — treat rank as a hint when fit is missing. authenticity (medium only) is advisory and prompts human review, never an automatic decision; active human corrections replace the original risk and reasoning. opted_out candidates count as SCREENED so they surface in the review queue, but never interviewed and carry no fit. </instructions> <response_format> Minimal (default): {"screen_id", "candidates": [{"candidate_id", "name", "stage", "overall_fit", "decision", "opted_out", "admitted_at"}], "total_count", "has_more"} Medium adds per candidate: {"bluf", "interview_status", "interview_completed_at", "decided_at", "decision_feedback", "authenticity": {"ai_use": {"risk", "reasoning"}, "misrepresentation"}} </response_format> <data_model>See list_screens for the Screening data model.</data_model>

list_screen_candidates

<usecase> List the Screening screens you can access, with ATS job posts, active plan version, unpublished-edit flag, and roster counts by stage. Use this to find a screen, then get_screen_details for its interview plan and version history, or list_screen_candidates for its candidates. </usecase> <instructions> Access: ATS hiring-team membership, admin, or explicit share. candidates.screened is the queue awaiting a human decision. has_unpublished_changes: the draft differs from ACTIVE and is not live until published in the web app. No active_version = never published. </instructions> <response_format>{"screens": [{"id", "job_title", "location", "ats_job_post_ids", "active_version"?: {"version", "lifecycle_state", "is_draft", "changelog", "created_at", "activated_at", "activated_by"}, "has_unpublished_changes", "candidates": {"pending", "pre_screen", "screened", "progressed", "rejected"}, "created_at", "updated_at"}], "total_count", "has_more"}</response_format> <data_model> - SCREEN: the per-job record (plan, roster, results), optionally linked to ATS job posts. Each candidate takes an AI interview scored against the plan. - PLAN: question sections + role/company context; one persistent DRAFT plus published versions, exactly one ACTIVE (what live interviews run against). Publishing a scoring change re-scores undecided interviews. - STAGE (derived): PENDING -> PRE_SCREEN (admitted + invited; spends a credit) -> SCREENED (interviewed, or opted out) -> PROGRESSED / REJECTED (human, terminal; syncs to the ATS as stage moves and rejections where wired). - FIT: band only (great/good/okay/no_evidence/poor), no numeric scores. AUTHENTICITY (ai_use, misrepresentation: LOW/MEDIUM/HIGH) is advisory. - OUTREACH: invitation email + schedule; deadlines snapshot at admission. - Writes: update_screen_plan and update_screen_outreach only; all else read-only. </data_model>

list_screens

<usecase> List sequences the current user can access, or fetch one sequence's full detail (pass sequence_id). Admins see all workspace sequences; non-admins see sequences they created plus any sending from their mailbox. Archived sequences are excluded. Summary rows include per-sequence stats for comparison without further calls. Related: list_sequence_candidates for enrolled candidates, manage_sequence to create/edit, list_mailboxes for sendable mailboxes. </usecase> <instructions>Pass sequence_id or include_detail=true to get full step configuration. Test sends and email previews are only available in the Metaview web app.</instructions> <response_format> {"sequences": [{"id", "name", "description", "is_enabled", "is_valid", "is_modifiable", "created_by": {"name"}, "created_at", "updated_at", "step_count", "stats": {"total_candidates", "total_active", "total_completed", "total_paused", "total_sent", "total_replies", "total_bounced", "total_interested"}, "steps"? (with include_detail)}], "total_count", "has_more"} </response_format> <data_model> - A SEQUENCE is an outreach campaign of ordered steps. Sequences can be enabled/disabled, lock (non-modifiable) once the first email is sent, and only their creator can edit them. - A STEP is one action in a sequence (channel types: EMAIL, LINKEDIN_CONNECTION, LINKEDIN_INMAIL, LINKEDIN_MESSAGE, SMS, PHONE, WHATSAPP) with content templates and a schedule; it executes automatically or manually. - A CANDIDATE SEQUENCE is one candidate's enrollment in a sequence: per-step delivery status, can be paused/resumed/cancelled, supports per-candidate template and schedule overrides. - A MAILBOX is an email account that can send sequence emails; its id is the from_mailbox_id for EMAIL steps. A SEND-ON-BEHALF PERMISSION lets one person send as another (per-person or workspace-wide). </data_model>

list_sequences

<usecase> List candidates surfaced in a sourcing search, with profile summaries, feedback status, pack number (which batch each candidate was presented in), and the user's remaining candidate credits. Hidden candidates (not yet revealed due to credit limits) are excluded. Use this to review candidates, check which still need feedback, and get candidate IDs for give_sourcing_feedback or referenced in get_sourcing_messages candidate attachments. </usecase> <instructions>For searches with 100+ candidates, paginate with limit=50 and iterate via offset — do NOT fetch all candidates in one call, it will exceed most agents' context limits. remaining_credits is "platform_credits" when the workspace pays for Sourcing with shared credits.</instructions> <response_format>{"search_id", "candidates": [{"candidate_id", "name", "linkedin_url", "pack", "summary"?: [{"title", "description"}], "profile"?, "feedback"?: {"accepted", "text", "author"}}], "total_count", "total_packs", "has_more", "remaining_credits", "next"}</response_format>

list_sourcing_candidates

<usecase> List the sourcing knowledge base — reusable instructions the sourcing agent applies while running searches (e.g. target companies, sourcing preferences, evaluation guidance). Returns workspace-scoped entries plus your own personal entries. Call this before manage_sourcing_knowledge to check whether an entry already covers a topic — prefer updating an existing entry over creating a near-duplicate. </usecase> <instructions>name is the trigger (WHEN the agent should apply the entry); content is the instruction (WHAT to do). disabled=true means you personally opted out of that entry. Always-enabled entries ignore all personal opt-outs; can_toggle=false means the caller cannot opt out. is_editable=false entries are locked by an admin or owned by someone else.</instructions> <response_format>{"knowledge": [{"id", "name", "content", "scope", "disabled", "is_locked", "is_always_enabled", "can_toggle", "is_editable", "created_at", "updated_at"}], "total_count"}</response_format> <data_model>See get_search_details for the sourcing data model definitions (searches, agent phases, candidates, feedback, ICPs, scheduled searches, search-sequence links, posting to ATS).</data_model>

list_sourcing_knowledge

<usecase> List your sourcing and research searches with summary information — title, mode (source/research), candidate count, agent phase, and timestamps. Use it to find a search to resume or to spot searches with candidates awaiting feedback. Check it before starting a new search: if one in the same mode already covers the role, follow up on it via send_sourcing_message with its search_id instead. For a single search's full state (ICP, version history, calibration, pack history) use get_search_details. </usecase> <instructions>Searches are ordered newest-first and scoped to searches you created.</instructions> <response_format>{"searches": [{"id", "title", "mode", "phase", "candidate_count", "created_at", "updated_at"}], "total_count", "has_more"}</response_format> <data_model>See get_search_details for the sourcing data model definitions (searches, agent phases, candidates, feedback, ICPs, scheduled searches, search-sequence links, posting to ATS).</data_model>

list_sourcing_searches

<usecase> Add candidates to a sequence, or pause, resume, cancel, remove, or update one candidate's enrollment (dispatch on action). Only the sequence creator can perform these actions. cancel stops further sends but keeps the candidate visible in the sequence; remove deletes (archives) the enrollment entirely. IMPORTANT: Always describe the exact changes and get the user's explicit approval before calling this tool. </usecase> <instructions>Get candidate_sequence_id values from list_sequence_candidates; get candidate_sequence_step_id values from the same tool with include_detail=true. Check find_candidate_in_sequences before adding to avoid duplicate outreach.</instructions> <response_format> Add: {"added": N, "sequence_id", "candidate_sequences": [...]} Pause/resume/cancel/remove: {"action": "paused|resumed|cancelled|removed", "candidate_sequence_id"} Update: {"updated": true, "candidate_sequence_step_id"} </response_format>

manage_candidate_sequence

<usecase> Create, update, or delete an AI Notes custom template (dispatch on action). WARNING — passing sections on update REPLACES the entire section list: omitted sections are permanently removed. Fetch the current sections with get_note_template first and resend every section you want to keep. Template ids are INTERNAL — never show them to the user; refer to templates by name. </usecase> <instructions>Design guidance: write every section description like a production LLM prompt — explicit scope plus an output-format contract (descriptions under ~200 characters produce vague notes). Bias toward one REPEATING section over several near-identical SINGLE sections. Split sections when outputs have different shapes or the user iterates on them independently. Use OPTIONS sparingly: 2-5 well-defined values with per-option criteria; a 6+ value enum is usually a classification a TEXT section handles better.</instructions> <response_format> Create / update: {"template": {template detail}} Delete: {"deleted": true, "template_id"} </response_format>

manage_note_template

<usecase> List, add, or remove sources on an existing AI Notes version (dispatch on action): inspect which conversations and documents are included, add extra conversations so the notes cover multiple interviews, add a plain-text document (e.g. a resume or job description) as context, or remove a previously added source. The notes must already exist — call generate_notes first if not. WARNING: adding or removing sources triggers a FULL regeneration of the notes. </usecase> <instructions>After add/remove, wait ~30 seconds then poll search_conversations(conversation_ids=[...], fields=["default:summary"]) yourself — do not ask the user. The anchor conversation's source cannot be removed.</instructions> <response_format> list: {"sources": [{"source_id", "type": "session"|"document", "name"}]} add: {"status": "sources_added", "added_source_ids": [...]} remove: {"status": "sources_removed", "removed_source_ids": [...]} </response_format>

manage_notes_sources

<usecase> Create, update, duplicate, or delete a sequence (dispatch on action). Only the creator can update or delete; admins and creators can duplicate. WARNING — updating with steps is a FULL REPLACE: steps omitted from the list are permanently deleted. Test sends, email previews, and send-now are NOT available here — direct users to the Metaview web app. IMPORTANT: Always describe the exact changes and get the user's explicit approval before calling this tool. </usecase> <instructions>Fetch current steps with list_sequences(sequence_id=...) before updating steps, and resend every step you want to keep. Sequence structure cannot change once candidates have started it — duplicate instead. Get from_mailbox_id values from list_mailboxes.</instructions> <response_format> Create/update/duplicate: {"sequence": {sequence detail with steps}} Delete: {"deleted": true, "sequence_id"} </response_format>

manage_sequence

<usecase> Create, update, or archive a sourcing knowledge entry (dispatch on action). Knowledge entries are standing instructions the sourcing agent applies to every matching search — use them to teach the agent durable facts and preferences (target companies, disqualifiers, outreach rules), not one-off search tweaks. Call list_sourcing_knowledge first and update an existing entry instead of creating a near-duplicate. Archiving is permanent in the UI (no unarchive) and rejects any pending suggestions for the entry. </usecase> <instructions>Write name as the trigger condition (when to apply, e.g. 'When sourcing for engineering roles') and content as direct instructions to the agent. scope=workspace applies to everyone in the workspace; scope=personal applies only to you. Workspaces can restrict creating workspace entries (or moving entries into workspace scope) to admins; entry owners can edit their own unlocked entries. Archiving always-enabled entries requires an admin; changing their scope requires turning off the workspace policy first. update only changes the fields you pass.</instructions> <response_format> Create / update: {"knowledge": {"id", "name", "content", "scope", ...}} Archive: {"archived": true, "knowledge_id"} </response_format>

manage_sourcing_knowledge