How to connect Develop21 MCP with Cursor

The starting point of a Develop21 thread - typically the first call, and the answer whenever the user asks what's going on, where they are, or what to do next. Returns their current state: a short profile summary, saved jobs and searches with what needs attention, plan and limits, the FIELD NAMES Develop21 stores, and how to update them. Light by design - when a task needs the full profile, develop21_get_profile returns every field with a resume SUMMARY standing in for the resume (token-light); add include_resume: true only when the full resume text itself is needed.

Use when the user wants to test or verify their Develop21 connection ("test Develop21", "is Develop21 connected?"). Optionally send a short note. Returns a confirmation of the connection and account. Only for connection checks, not for career tasks.

Report a problem with, or suggest an improvement to, a Develop21 response - use when a tool did not work as described (bug, data issue) or you see a concrete enhancement. Send the response_id of the affected response, a score, and what happened. If unsure whether to report, ask the user first. One report per response_id. Not for user feedback about jobs or employers.

Use when the user wants Develop21 to keep a document - resume, cover letter, profile notes, or a review verdict. Send name, doc_type and full content (plus opportunity_id when the document belongs to a job). During co-editing, send delta {find, replace, seq} instead of content to apply one accepted change. Not for your conversation memories or ratings.

Use when the user wants a document previously saved to Develop21 ('get my saved resume', 'read back X', 'what documents do I have?'). Send name or id for one document; send nothing to list all saved documents. Returns the document content and fields. Only for documents saved via develop21_save_document.

Use when a new user wants to set up Develop21, shares a resume, or says 'create my Develop21 profile'. Extract whatever fields you already have evidence for per the schema (empty is fine - never guess) and send them. Returns the remaining setup steps for the profile. Changes to an existing profile go through develop21_update_profile.

Use when the user shares new or changed career information - new role, new preferences, corrected details - or asks to review what Develop21 knows about them ('update my profile', 'my salary expectation changed'). Send only fields with user-confirmed evidence. First-time setup goes through develop21_create_profile.

Download the complete stored career profile - every field value, plus the briefing, optionally the full resume text. Use when a task needs the whole profile, or the user asks to see or export everything Develop21 holds about them. For a light session-start snapshot and what-to-do-next, use develop21_user_state instead. Set include_resume true to include the resume text. Read-only.

Use when the user shares a job posting or asks whether a job suits them ('review this job', 'am I a fit?', 'should I apply?'). Send title, company and the FULL description text - or just opportunity_id for a job already saved (e.g. an extension capture listed by develop21_get_job); its stored description is used server-side, do not resend it. Returns Develop21's evaluation rubric together with the user's stored profile. Saves the job for later steps.

Use right after reviewing one or more jobs with develop21_review_job_fit, to SAVE the verdicts so they are not lost. Send a reviews array; each: opportunity_id (the uuid exactly as Develop21 tools returned it), whole-number score 0-10, the full verdict text (kept as the job's review document - required unless the job already has one), and optional decision ('pursue' | 'pass' | 'dismiss'). Records the score and stage on each job (passed/dismissed jobs leave the review queue); records a whole block in one call. On the free plan the call is refused before anything is written when the new review documents would pass the document limit - free space first.

Use when the user wants to quickly sort through the jobs they've captured but not yet reviewed ('triage my captures', 'sort my saved jobs', 'which of these are worth it?'). No arguments - returns every not-yet-reviewed captured job with its tier-0 fields (title, company, location, salary, posting date) plus the user's lens, for a fast advance/park/dismiss pass. Deep review of the survivors is develop21_review_job_fit.

Use when the user asks about jobs saved to Develop21 ('what jobs have I captured?', 'the job I sent from the extension', 'review my latest capture'). Send nothing to list saved jobs (newest first), or title/id for one job. A listed job can be evaluated with develop21_review_job_fit using its id - the stored description is used server-side.

Use when the user asks what Develop21 can do or how to do something with it ('how do I delete a document?', 'can Develop21 track my applications?', 'what is this connector for?'). Send a topic for specifics, or nothing for the overview.

Use ONLY when the user explicitly asks to delete a document saved to Develop21 ('delete my old cover letter', 'remove the acme review'). Send name or id. Deletion is immediate and permanent - confirm with the user which document they mean before calling. The career profile is not a document; it changes through develop21_update_profile.

Use ONLY when the user explicitly asks to remove a job saved to Develop21 ('delete that Acme job', 'remove the listing I captured'). Send id or title. Deletes the job AND its linked documents and application history - when any exist, the first call returns what would be deleted; ask the user, then re-call with confirm true.

Use when the user REPORTS an application outcome in conversation - applied ('I sent it', 'just applied'), deciding to pass, waiting on a response, or hearing back (interview, offer, rejection). The report is the cue: log it as part of keeping good notes, then acknowledge briefly - the user rarely thinks to ask. Send the opportunity_id from the job's review and the event. A current tracker is what makes the next develop21_user_state true, spares decided jobs from re-review, and powers honest check-ins. Returns brief stage-appropriate context.

Use when the user wants their resume/CV tailored for a SPECIFIC job they've reviewed ('tailor my resume for the Acme role') - typically after a Go decision. Requires the opportunity_id from develop21_review_job_fit. Returns the tailoring procedure, the baseline resume and the job's language. For general improvement of the master resume with no job in play, use develop21_update_master_resume.

Use when the user wants to improve their master resume with no specific job in play ('update my master resume', 'improve my CV'), or to BUILD the master resume when none exists yet. No arguments - Develop21 reads back the stored master resume as the baseline. Returns the editing procedure and that baseline - or the build-from-scratch procedure when there is none. For tailoring to a specific reviewed job, use develop21_tailor_resume.

Use when the user wants a cover letter written or improved for a job ('now the cover letter', 'help with my cover letter') - typically after tailoring the resume. Send the opportunity_id from the job's review. Returns the writing procedure, the tailored resume, and the job's language and voice notes.

Use at document completion to run the AI-writing check, and when the user pastes back a pangram.com result link. action:'prepare' returns the check pack - the not-yet-certified text of a document (send name or opportunity_id+doc_type, or content itself at profile intake) with the user's steps for a free check at pangram.com. action:'record' (send share_url) reads the shared result while the link is public, verifies it matches the pack, stores the verdict, and certifies the human-written paragraphs for reuse; its reply includes a reminder to relay: the user can set the share back to Private.

Use when the user wants to protect a saved job ('favourite the Acme role', 'keep that one safe') or release one ('unfavourite it'). Send id or title, and favourite false to release. A favourited job is never replaced when a new capture needs a slot, and its documents don't age out; on the free plan, at most nine of ten slots can be favourites (a paid plan has no limit).

Use when the user wants to find new or more jobs, or none of their saved jobs fit. Develop21 compiles starting queries from the career profile for job-search connectors (ZipRecruiter, Indeed, Dice, JobDataLake, JobGet, Aquent, FoundRole, SonicJobs, Reed.co.uk, Jobtome), plus ready-to-open LinkedIn search links (no connector needed - the user clicks them in their own browser), coaches narrowing until a search returns a readable pool, and saves the TESTED query as a plan. The searches run on those connectors or in the user's browser, not here. Start with action:'plan' (send engines_available = job-search tool names visible in this conversation). Running the saved plans day to day is develop21_execute_job_search.

Use when the user wants to RUN their saved job searches - the daily loop ('run my job searches', 'run my saved searches'). action:'list' returns the saved plans with the run and read protocol; report the totals back with action:'update' runs:[...]; action:'check' dedupes result rows against every job the account has already seen (title, company, url only - never descriptions; a url ALONE also works, e.g. a job link the user shared from their phone; a batch_id from the Develop21 extension's list capture loads those rows server-side). Mid-run, check with store:true BANKS engine rows instead of triaging them; at the end of the run, check with batch_scope:'pending' sweeps every banked list, browser capture and forwarded email together into ONE shortlist. Compiling NEW searches is develop21_plan_job_search.