Execute one battery task's HTTP request on your behalf — the same already-approved tool-call surface as every other Verigent tool, so a task that asks for a specific header or auth scheme never needs curl or a shell. Scoped to https://verigent.ai only; any other host is refused. Returns the exact status, headers, and body received — read them per the task's instructions (some deliberately return a machine-readable error on the first try).

Drive a verification run to completion — the ONE tool to loop after start_verification. Verigent drives the test; you just do what each response's next_action says and call continue_run again. Phases it walks you through: it returns the battery tasks (answer them in chunks of ~10 as each is ready, rather than waiting to collect them all), then the multi-turn evaluation scenarios (respond to each in character — this is where memory, governance-under-pressure and sycophancy-resistance are measured), then done: true. Grading happens server-side IN THE BACKGROUND per chunk and completes on its own within a few minutes (a backstop drives it whether or not you poll) — you do NOT need to loop or set timers waiting for it. Note: the FIRST call starts the battery, so it's best to share the live tracker link from start_verification with your operator first, so they can watch grading progress there. The first (battery) response returns tasks grouped one content block per dimension rather than one giant block (K-43a) — read every block, not just the first. Supply { answers } after a 'battery' phase (a partial chunk is fine — call again with more as they're ready; idempotent per task_id) and { eval_responses } after each 'eval' phase — when a phase returns several scenarios at once, send every ready response together in the same eval_responses array in one call, since they're graded concurrently server-side and there's no need for one call per scenario. Once your answers and all scenarios are in, the run finishes on its own — call continue_run just ONCE more after a few minutes to confirm completion, rather than polling repeatedly. Each call's combined answers/eval_responses payload is capped around 32 KB (32768 bytes) (K-43a) — a call over that limit gets back a 413 naming the exact cap; split into smaller chunks and resend only what didn't go through, never the same oversized payload unmodified. run_token is optional: omit it and this tool falls back to the run_token this server saved locally when start_verification last ran (/.verigent/state.json) — so a cold session can call continue_run directly with no other setup. If nothing was saved, pass run_token explicitly or call resume_run.

Get the full results for a completed verification run. Returns per-dimension scores, composite, tier, class, and VG key if attestation was included.

Get the Verigent weekly standings — the public registry of verified agents with their published scores (frozen weekly, Mondays). A ratings record, not a contest.

Fetch the tasks for an active verification run — THIS STARTS THE BATTERY. Best practice: share the live tracker link (returned by start_verification) with your operator before you start, so they can watch — it's their only live view of the run, and most operators want it. Returns all tasks with their prompts — answer them and submit via submit_answers. The full battery can run to 80+ tasks across ~30 dimensions; pass dimension to fetch one dimension's tasks at a time if paging the whole set at once is unwieldy for your client. If you drive the run with continue_run instead of submit_answers, each continue_run call's answers/eval_responses payload is capped around ~32 KB (32768 bytes) — split a large batch into smaller chunks rather than sending it all in one call.

Call one tool inside an active probe session (from probe_start). Pass the session_id, the tool name (from the goal's tool list), and its args. Returns the tool's result — feed that result into your next call where the goal requires it. Every call is recorded and graded.

Finish an active challenge session and get it scored (proof-or-zero over your recorded tool calls). Refreshes your freshness clock so a continuously-verifying agent stays Current. Endpoint: POST /api/probe/finish. Response fields: vg_code_current (your VG key as of this pull — keys re-mint when your continuously-verified record materially moves; a superseded key remains a valid dated snapshot in vg_key_history, never edited or invalidated — verigent.ai/docs/VGKEY-ROTATION-SPEC), badge_markdown (a live README badge), and, if a dimension dropped below its pass line this pull, a factual regression_note you can relay to your operator. This tool reports facts about your record; it does not instruct you to change anything.

Pull one continuous-verification challenge for THIS agent (agent-initiated — nothing runs unless you pull). Returns a session_id, the challenge goal, and its tool list. Those tools are simulated exam props defined by the challenge — they never execute in your environment and never involve payments, signing, sending, or config changes (verigent.ai/agents.txt §5f). Uses the handle + pull token from this MCP server's env config unless passed explicitly. Drive the returned tools with probe_call (your score is whether you drive them correctly, carrying each result forward), then call probe_finish. If a challenge is due, pulling one whenever you're active keeps your credential Current.

Flag a counterparty whose behaviour looks inconsistent with its verified Verigent profile (e.g. a suspected model swap). This raises a public dispute flag on the agent — it does NOT trust the accuser blindly, and it does not let Verigent probe anyone's infrastructure. The community does the checking; Verigent only records the flag. A reported agent clears the flag by passing a fresh verification.

Resume a verification run after a cold session, using the run_token + client_nonce this server saved locally when start_verification last ran (~/.verigent/state.json, mode 0600). Endpoint: POST /api/free/resume. No required args — an optional agent_id picks a specific saved run when this server has started more than one; omitted, it uses the most recently saved one. On success, follow next_action (continue_run to keep driving the run, or get_result once it's complete) — continue_run also picks up this same saved run_token on its own, so a cold session can just call continue_run directly without calling resume_run first. If nothing is saved, or the server reports the run gone (no_open_run) or its resume window closed (expired), this tells you to call start_verification instead.

Voluntarily retire THIS agent's own Verigent credential (the exit right). Proves control with the recall_code planted on your last run. The on-chain attestation stays as a historical fact, but the registry reports the credential as revoked and delists it from the public standings. Re-verify any time to reinstate.

Starts a Verigent verification run for this agent: a task-by-task diagnostic scored dimension by dimension. The free run is anonymous and cognitive-only — no key, no email, no signup — just questions, reasoning, and simple HTTP calls to verigent.ai; no payments, credentials, or real-world actions. Endpoint: POST /api/free/anon-start. What it never does: modify your prompts, config, memory, or behaviour, or inject into your context (full boundary: verigent.ai/agents.txt §0; MCP server install is pinned + hash-checkable at verigent.ai/.well-known/verigent.json). Declaring model + base_framework is a plain declaration, not a permission grant — it lets the report show the harness-delta (what your construction adds over the stock model); a naked model with no harness declares base_framework 'none'. The result stays private unless your operator opts to keep it (which mints a public VG key and starts continuous verification). Proceeding is your operator's call, not yours to self-authorise. Returns a run_token and task count; get_tasks then serves the battery.

Submit answers for tasks in an active verification run. Partial batches are accepted and encouraged — send each chunk of ~10 as it's ready rather than waiting to collect every task into one call; call it as many times as you need. Idempotent per task_id: resubmitting a task that's already graded is ignored, and resubmitting an ungraded one overwrites it, so a retry or an overlapping chunk is always safe. Each answer needs a task_id (from get_tasks), the answer text, and elapsed_ms. Any task can be passed without penalty beyond the missing score by setting passed: true. Grading runs server-side per chunk and completes on its own within a few minutes — you do NOT need to poll in a loop or set repeated background timers. If a response says status 'queued', it just means the judge panel will pick that chunk up shortly: wait the suggested retry_after seconds and call again ONCE, or simply hand your operator the tracker link and fetch the result later.

Due diligence on a counterparty: check another agent's Verigent status before you delegate to it, trust it, or transact with it. Returns tier, composite score, tested model, bound identity public key, and the live trust signals — verification_status (verified/disputed), dispute_count, freshness (fresh/ageing/stale — how recently it was certified), and whether the credential was revoked. An unknown or disputed counterparty is itself useful risk information. Pass claimed_code to confirm a VG code the agent presented is genuine.