mcpforwork
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| report_playbook_resultB | Opt-in crowd-learning: report what worked/moved/broke on a source (kind: success | drift | break) to improve the next pack version. |
| server_infoA | Version + capability handshake: server version, registered tools, and the load-bearing invariants the client must respect. |
| create_profileA | Create a new profile (made active) and return it. |
| get_profileA | Return the active profile (or a given one), JSON fields parsed. |
| update_profileA | Apply a partial update. With no profile_id, updates the active profile — or creates it if the user has none yet (the /setup path). |
| list_profilesA | List the user's profiles (the active one has is_active=1). |
| set_active_profileC | Switch the active profile. |
| add_achievementsB | Append quantified wins (each needs a |
| set_style_profileC | Capture the user's writing voice so drafts sound like them. |
| import_from_url_findingsA | Apply client-LLM-extracted structured fields (LinkedIn/GitHub/portfolio) to the active profile, recording the source url for provenance. Call ONLY after preview_url_import + human CONFIRM — this tool writes. |
| preview_url_importA | Read-only LinkedIn/GitHub/portfolio import preview (S5.4). |
| hunt_planA | Per-source search playbooks for the active profile — the URLs YOU open in the user's browser to find postings. |
| source_playbookC | The full search + apply playbook for one source. Pack data only — no DB. |
| list_sourcesA | List enabled sources, optionally filtered by country/sector tags. Pack data only — no DB. |
| submit_findingsA | Ingest postings YOU extracted from a source: deduped, scored against the profile, and persisted. Each finding needs at least url + title. |
| check_seenA | Report which URLs the copilot already knows (scouted or applied). Only browse/apply the ones marked 'new'. |
| list_matchesC | The scouted matches, best score first. |
| get_matchB | Inspect one scouted match by id. |
| pipeline_statsA | Pipeline counts for a status summary: new matches, awaiting the human, submitted/verified, responses. The same read the dashboard shows. |
| get_autopilot_policyA | The active autopilot (L2) policy: min_score, max_per_day, since when. null policy = autopilot off, every submit awaits the human. Policies are written ONLY from the dashboard (human session) — never here. |
| autopilot_queueA | The L2 work queue: approved matches on auto_apply_safe boards scoring at/above the policy min, not dedup-blocked, with no open application. Empty when autopilot is off or no board is flagged safe. Read-only. |
| get_generation_briefB | The structured brief (job keywords + facts inventory + style + honesty rules) YOU draft the cv/cover_letter from. Only claim what the facts_inventory proves. |
| submit_assetB | Store YOUR draft (markdown) for a match; versions auto-increment. |
| get_assetsC | The stored drafts for a match, newest version first. |
| ats_coverage_checkB | Deterministic check of the posting's keywords vs a stored draft: covered / missing_but_have (truthfully addable) / genuine_gaps (acknowledge, never stuff). |
| approve_matchB | Approve a match (human decision) so materials/apply can proceed. |
| discard_matchA | Discard a match (human decision); it will never be re-surfaced. |
| start_applicationA | Start a supervised application session for an APPROVED match: runs the preflight (dedup gate, daily cap) and returns the step plan YOU execute in the user's browser. The plan never contains a submit step — request_submit is the only submission route and the human decides. |
| report_apply_progressA | Report a step's outcome (ok | blocked | mismatch). The server answers with the next step, a repair, or a human-pause — never a submit. |
| resolve_fieldA | Deterministic answer for an unpredicted form question — from the profile or saved answers; otherwise ask_user (never invent). |
| save_form_answerA | Persist a HUMAN-confirmed screener answer so it is never asked twice. |
| abandon_applicationA | Close an application you decided not to pursue (any open state). A later start_application for the same match opens a fresh session. |
| request_submitB | THE consent gate. Ask permission to move to submission: at consent level 0 the answer is always await_human — show the filled form; the HUMAN clicks Submit. |
| confirm_submittedB | AFTER the human confirms they clicked Submit: close the loop (state, dedup record, audit). |
| record_outcomeB | Record what happened (no_reply|rejected|interview|offer|hired) — feeds calibration. |
| get_asset_fileC | A local file path for the asset (for form uploads). |
| record_applicationA | Record that the HUMAN submitted an application (any channel) so the copilot never re-surfaces the posting. Idempotent per URL. |
| profile_gapsA | What the profile is still missing (required first, then progressive). Offer ONE gap at a time when contextually useful — never a form-wall. |
| parse_cvA | Zero-LLM regex extraction of contact fields from pasted CV text. Returns candidate fields (None = unknown — ask the human, never invent). Does NOT write the profile: CONFIRM with the human, then call update_profile. |
| export_my_dataA | GDPR data portability: everything stored about you (profile, findings, applications, assets, audit trail) as one JSON object. Read-only. |
| delete_my_dataA | GDPR erasure, two-step (S7.2d): called WITHOUT a token, returns a per-table summary of what would be deleted plus a single-use confirm_token (valid 5 minutes) — show both to the human. Called WITH that token, permanently deletes ALL their data (every table + the account row). IRREVERSIBLE. The token is the consent artifact: never invent one — only the human can read it back to you. Consider export_my_data first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| setup | The /setup interview: CV-first focus, then fill remaining Tier-1 gaps. |
| review | The /review loop: triage scouted matches with the human. |
| apply | The /apply flow: brief → honest draft → coverage → browser fill → consent. |
| hunt | The /hunt playbook: turn the profile into searches, browse, ingest, review. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 41 tools
Most tools have clearly distinct purposes, but a few pairs like hunt_plan/source_playbook and parse_cv/preview_url_import could be confused without careful reading. However, the detailed descriptions effectively disambiguate them, and the application workflow tools each have specific roles.
The majority of tools follow a verb_noun pattern (e.g., get_profile, create_profile, submit_asset), but some read-only data tools use noun phrases (e.g., pipeline_stats, autopilot_queue, ats_coverage_check, profile_gaps) and a few use less standard verbs (preview, hunt, check, request). Overall, the naming is readable and mostly consistent.
With 41 tools, the surface is very large and exceeds the threshold for 'too many'. The domain is broad, but the granularity exposes many fine-grained workflow steps (e.g., confirm_submitted, record_outcome) that could be grouped into higher-level tools, making the set overwhelming for agents.
The tool surface covers the full lifecycle: profile creation/import, job hunting, match management, drafting, application execution, and GDPR data rights. Minor gaps exist, such as no dedicated tool to get an application's current status and no update/delete for achievements, but core workflows are well covered.