Huntr MCP Server

Huntr for Organizations

Huntr for Organizations powers advisor dashboards that track job seekers ("members") through their job search. The org API is read/write across the entities that appear in those dashboards. It is not the consumer Huntr app for individual job seekers — it only works for accounts on Huntr's organization (advisor) plan.

Core entities

• Advisors — staff/coaches inside the organization who manage members.
• Members — job seekers in the organization. Members can have member field values populated from the org's custom Member Fields, and can be grouped into Member Groups.
• Organization Invitations — pending invitations sent to prospective members; an invitation can pre-assign a board template, member field values, and an advisor.
• Candidates — talent-portal profiles tied to a member (resume, headline, work history, salary expectations, location, role/industry preferences). Each candidate has Candidate Action Metrics (counts of actions by type and timeframe).
• Board Templates — pipeline templates applied to new member boards.
• Jobs — application cards a member is tracking on their board.
• Job Posts — opportunities posted to the org's white-labeled job board, optionally shared with specific members or member groups.
• Tags — labels applied to job posts.
• Activities — to-do/done items on a board (Apply, Phone Interview, Offer Received, etc.) classified by Activity Categories.
• Actions — append-only audit feed of what happened in the org (e.g. JOB_CREATED, ACTIVITY_CREATED, NOTE_CREATED). The Events resource is deprecated; use Actions instead.
• Notes — internal member notes written by advisors.
• Goals — recurring or one-time objectives (e.g. "5 applies per week"). Members participate via Goal Enrollments, which produce Goal Progresses per interval.
• Employers — companies attached to jobs/job posts, optionally marked as partners.
• Webhooks — Huntr can POST signed action payloads to a configured URL when actions occur.

What you can do

• Read: list/inspect advisors, members (and a single member), member groups, member fields, candidates (and candidate action metrics), board templates, jobs, job posts, tags, activities, activity categories, actions, internal member notes, goals, and employers. All list endpoints support cursor pagination via next and a limit (default 100, max 500 on candidates).
• Filter: members by active; candidates by email/memberId; jobs by owner/creator/created window; activities and actions by owner/creator/job/category/employer/created window; actions also by action_type/activity_id/note_id/contact_id.
• Write: invite a member to the organization; create a member field; update a member's member-field value; create a job post and (optionally) share it on creation with members or member groups; bulk-send existing job posts to members; create tags; create and delete internal member notes; enroll a member in a goal.

Pagination and shape

• Most list endpoints return { "data": [...], "next": "<cursor>" }. Pass that cursor back as next to fetch the next page. limit defaults to 100.
• Tags are returned as a bare array, not a {data, next} envelope.

Common workflows

• New cohort: list member-groups → create custom member-fields → invite each job seeker via an organization invitation pre-populated with boardTemplateId, memberFieldValues, and advisorEmail.
• Track engagement: poll actions (filtered by created_after) to ingest a real-time-ish feed of what members and advisors are doing, or register a webhook on the advisor portal.
• Run a goal: list goals → enroll selected members via goal enrollments → monitor progress through the resulting goal-progress and action records.
• Share opportunities: create a job-post with memberEntries to push it to a list of members on creation, or use the job-posts/send-to-members endpoint to fan out existing job posts to additional members.
• Manage candidate pipeline: list candidates, drill into a single candidate, then pull candidate-action-metrics to see how active they have been.

Important constraints

• Events are deprecated. Use Actions for both CRUD-type and real-world (activity-derived) events. The Events resource will not gain new event types.
• Members and candidates are distinct: every candidate belongs to a member, but not every member has a candidate profile.
• Tag targetObjects is currently always JOB_POST.
• Goal enrollmentType of MANUAL requires explicit goal-enrollment creation per member.
• Webhook payloads use HMAC SHA-256; signatures must be validated against the per-webhook secret revealed in the advisor portal Developers tab.