# Agent Intern (pypi · agent-intern)

Delegate from Claude Code to Gemini, Codex, Copilot, Cursor and opencode CLIs as sub-agents.

- Trust score: 69/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-25

## Components

- pypi · `agent-intern`: 69/100 (this document), [markdown](https://verifymcp.io/servers/sinantufekci-agent-intern/agent-intern.md), [page](https://verifymcp.io/servers/sinantufekci-agent-intern/agent-intern)

## Channel facts

- Registry: `pypi`
- Package: `agent-intern`
- Version: `0.32.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-25.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs setuptools.build_meta at install time, a recognised native-build step with no shell scripting around it.
  - 1 of 14 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 64/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 10301 tokens (~355/item across 29 items; 29 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 29 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 30 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the Agent Intern MCP server?

Agent Intern runs locally as a PyPI package, launched with uvx agent-intern. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add sinantufekci-agent-intern -- uvx agent-intern
```

### Cursor

```json
{
  "mcpServers": {
    "sinantufekci-agent-intern": {
      "command": "uvx",
      "args": [
        "agent-intern"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "sinantufekci-agent-intern": {
      "command": "uvx",
      "args": [
        "agent-intern"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add sinantufekci-agent-intern -- uvx agent-intern
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "sinantufekci-agent-intern": {
      "type": "local",
      "command": [
        "uvx",
        "agent-intern"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add sinantufekci-agent-intern --command uvx --arg agent-intern
```

### Hermes

```yaml
mcp_servers:
  sinantufekci-agent-intern:
    command: "uvx"
    args: ["agent-intern"]
```

### Netclaw

```json
{
  "McpServers": {
    "sinantufekci-agent-intern": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "agent-intern"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add sinantufekci-agent-intern -t stdio -c uvx -a agent-intern
```

### Other

```json
{
  "mcpServers": {
    "sinantufekci-agent-intern": {
      "command": "uvx",
      "args": [
        "agent-intern"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-25 (score 69, +15)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-24 (score 54)

First indexed and scored.

## MCP tools (29)

### `antigravity_ask` (~1156 tokens)

Ask Antigravity (new conversation)

Ask Antigravity (agy CLI, Gemini by default) a question in a NEW conversation.

Uses your existing AI Pro authentication (silent-auth via Windows Credential
Manager). Returns the model's final response as text. Good for fast
tool-calling and short tasks; for heavier reasoning pick a bigger `model` or
use the host model directly.

Input parameters:

- `model`: Optional model slug to run this conversation on (agy's --model),    e.g. "gemini-3.1-pro-high" or "claude-sonnet-4-6". Omit to use the    model set in agy's settings.json (gemini-3.8-flash-high as of…
- `plan` (boolean): If true, run agy in PLAN mode (agy 1.1.12+): it investigates and   writes an implementation plan instead of touching anything. Verified   on 1.1.20 that a file write and a shell command are both refu…
- `prompt` (string, required): Question or instruction for Antigravity.
- `schema`: Optional JSON Schema (an object, or its JSON text). When given, agy     is asked to produce output matching it (agy 1.1.8's --json-schema)     and this tool returns the VALIDATED OBJECT as JSON text…
- `timeout_s` (integer): Max seconds to wait for agy to complete. Default 180.
- `watch` (boolean): If true, open a live "watch" view in your browser that streams    agy's steps (narration + the real commands it runs) as it works.    agy still runs headless; the same final text is returned. Best-…
- `workspace`: Working directory for the conversation. Defaults to cwd.        Choose an existing project dir for context-aware responses.

Output parameters:

- `result` (string)

### `antigravity_continue` (~462 tokens)

Continue Antigravity conversation

Continue the Antigravity conversation rooted at this workspace.

Resumes the exact conversation id recorded for `workspace` (via agy's
\--conversation flag), not agy's global "most recent", so it stays correct
even if agy was used elsewhere in between. On agy 1.1.8+ that id is the one
agy itself reported for this bridge's last run in the workspace, so a
follow-up resumes THIS thread even if you have since started a separate
conversation in the same folder from Antigravity's own interface.

Input parameters:

- `model`: Optional model slug for this turn (agy's --model), e.g.    "claude-sonnet-4-6". agy's model is per-invocation, not baked into    the conversation, so a follow-up can run on a different model than…
- `plan` (boolean): If true, run this turn in agy's PLAN mode (1.1.12+) — it investigates   and writes an implementation plan instead of editing files or running   commands, while reads still work. Per-invocation like `…
- `prompt` (string, required): Follow-up message.
- `schema`: Optional JSON Schema for this turn — returns the validated object as     JSON text instead of prose. Per-invocation like `model` and `plan`.     See antigravity_ask's `schema`. Needs agy 1.1.8+.
- `timeout_s` (integer): Max seconds to wait for agy to complete. Default 180.
- `watch` (boolean): If true, open a live "watch" view in your browser that streams    agy's steps as it works (same return value, best-effort). Default false.
- `workspace`: Working directory used by the prior conversation. Defaults to cwd.

Output parameters:

- `result` (string)

### `antigravity_image` (~278 tokens)

Generate an image with Antigravity

Generate an image with Antigravity (Gemini image model via agy CLI).

Drives agy to produce a raster image on your existing AI Pro quota, saves it,
and returns the absolute file path plus its real format and byte size. The
host can then read the path to view the image.

agy picks the image format itself (JPEG for photo-like images, PNG for flat
graphics), so the returned path's extension is corrected to match the actual
bytes (a requested out.png may come back as out.jpg). Runs a normal,
unsandboxed agy session — same privileges/caveats as the other tools (see the
module SECURITY note).

Input parameters:

- `output_path`: Where to save. Absolute, or relative to `workspace`. If          omitted, a timestamped name under `workspace` is used.
- `prompt` (string, required): Description of the image to generate.
- `timeout_s` (integer): Max seconds to wait for agy to complete. Default 240        (image generation is slower than text).
- `watch` (boolean): If true, open the live "watch" window that streams agy's steps and    shows the finished image inline (same return value, best-effort).    Default false.
- `workspace`: Working directory for the conversation. Defaults to cwd.

Output parameters:

- `result` (string)

### `agent_swarm` (~825 tokens)

Agent swarm (mixed Antigravity + Codex + Copilot + Cursor + …, parallel)

Run SEVERAL tasks IN PARALLEL across ALL backends in a single swarm.

Each task is its own worker and names the backend to run on, so one swarm can
mix Antigravity (Gemini), Codex, Copilot, Cursor, Grok, opencode and Muse workers —
they run truly concurrently (capped at `max_concurrency`) and every answer comes
back in one labelled block. A worker that fails is reported in place; the others
still return.

SECURITY: this launches N unsandboxed agents at once — N times the
prompt-injection surface of a single call (see the module SECURITY note). Only
use it with trusted prompts on trusted content.

Input parameters:

- `max_concurrency` (integer): Max workers running at once (default 4). Higher = faster              but more quota/rate-limit pressure and more agents at once.
- `tasks` (array, required): One object per parallel worker:    - backend: "antigravity" (alias "agy"/"gemini"), "codex",               "copilot" (alias "gh"/"github"), "cursor", "opencode"               (alias "oc" — the one ba…
- `timeout_s` (integer): Per-worker timeout in seconds. Default 180. An opencode        worker is given at least 300s regardless — its free models are        queue-scheduled and were measured at 152-428s, so the shared…
- `watch` (boolean): If true, open the live "Agent Swarm" dashboard window (one card per    worker, with its backend's logo; click a card for its full step log).

Output parameters:

- `result` (string)

### `preset_swarm` (~248 tokens)

Preset swarm (jury / research / red team / council)

Run a PREDEFINED swarm: a named panel of agents from different model
families, each in its own role, all working on the same material in parallel.
One call instead of building agent_swarm tasks by hand, and the same panel
every time, so two runs (two applications, two drafts) can be compared.

Input parameters:

- `material` (string, required): The text the panel works on, in full.
- `max_concurrency` (integer): Members running at once (default 4).
- `preset` (string, required): The preset's name, e.g. "jury", "research", "red-team", "council",     or one of the user's own.
- `timeout_s`: Per-member timeout in seconds (default: the preset's own,        240-360s for the built-ins). opencode members get at least 300s.
- `watch` (boolean): If true, open the live "Agent Swarm" dashboard, one card per    member, captioned with its role.
- `workspace`: Directory the members run in, and whose        .agent-intern/swarms/ presets are included (default: server cwd).

Output parameters:

- `result` (string)

### `swarm_presets` (~167 tokens)

Swarm presets (list, or show one to customise)

List the predefined swarms preset_swarm can run, or show one in full.

Lists each preset's kind, members (role and backend), rubric for a jury, and
where it comes from. Built-ins can be replaced or extended with JSON files in
\~/.agent-intern/swarms/ (every project) or <workspace>/.agent-intern/swarms/
(one project; its members run read-only and it cannot replace a built-in or
user preset, because it arrives with whatever repo was cloned). Broken files
are listed with the reason they were skipped.

Input parameters:

- `name`: Show this preset in full, as the JSON to save and edit. Omit to list.
- `workspace`: Project directory whose presets to include (default: server cwd).

Output parameters:

- `result` (string)

### `antigravity_image_swarm` (~246 tokens)

Generate several images in parallel

Generate several images IN PARALLEL with Antigravity (one worker per prompt).

Like antigravity_image, but runs N image generations concurrently in isolated
workers (capped at `max_concurrency`). Returns one block listing each image's
final path/format/size (or its error). Extensions are corrected to the real
bytes, exactly like antigravity_image. Same unsandboxed privileges/caveats as
antigravity_swarm.

Input parameters:

- `max_concurrency` (integer): Max workers running at once (default 4).
- `output_paths`: Where to save each image (aligned to prompts). Omit to write           timestamped files in the first workspace (or server cwd).
- `prompts` (array, required): One image description per parallel worker.
- `timeout_s` (integer): Per-worker timeout in seconds. Default 240 (images are slower).
- `watch` (boolean): If true, open the live dashboard; each finished image shows in its    pane, and clicking a row opens that agent's window beside the dashboard.
- `workspaces`: Working directory per worker (same shorthand as antigravity_swarm).

Output parameters:

- `result` (string)

### `antigravity_status` (~190 tokens)

agy bridge diagnostics

Report diagnostics for the agy bridge setup (spends no AI Pro quota).

Reports the bridge's own version and whether a newer release is available
(best-effort GitHub check; honors AGY_BRIDGE_NO_UPDATE_CHECK), then checks
whether agy is on PATH (and its version/compat), how much AI Pro quota is left
per model family (agy 1.1.11+ answers `/usage` in print mode for free — a
family at 0% is reported as a problem, since every call against it will fail
until its window resets), whether agy's state directories exist, whether the
newest conversation transcript is readable, and whether the SQLite
conversation store is present. Use this to debug empty or failed responses —
or to see if the bridge itself is out of date, or if you are simply out of
quota — before spending quota.

Output parameters:

- `result` (string)

### `codex_ask` (~497 tokens)

Ask Codex (new session)

Ask OpenAI Codex (`codex exec`) a question or task in a NEW session.

Uses your existing Codex login (ChatGPT or API key — see `codex login status`).
Returns the agent's final message as text, read from codex's
\--output-last-message file (no stdout scraping). Codex is a capable coding
agent, so this suits heavier reasoning and real code work, not just cheap
tool-calling. Point `workspace` at a real project dir for context-aware answers.

Input parameters:

- `model`: Optional model override (`-m`); omit to use codex's configured default.
- `prompt` (string, required): Question or instruction for Codex.
- `sandbox` (string): Filesystem policy — "read-only" (default: reads and answers but      writes nothing), "workspace-write" (may edit files under the      workspace), or "danger-full-access" (no sandbox — avoid). `codex…
- `timeout_s` (integer): Max seconds to wait for codex to complete. Default 180.
- `watch` (boolean): If true, open a live "watch" view in your browser that streams    codex's steps (reasoning, the commands it runs, file changes) from    its `--json` event stream. codex still runs headless; the same…
- `workspace`: Working root for the session (`-C`). Defaults to the server cwd.

Output parameters:

- `result` (string)

### `codex_continue` (~184 tokens)

Continue Codex session

Continue the Codex session rooted at this workspace (`codex exec resume`).

Resumes the exact session id captured from the last codex_ask in this
workspace, falling back to the newest on-disk session whose recorded cwd
matches (so it still works after a server restart). The resumed session keeps
its original sandbox and model — those are chosen when you start it with
codex_ask.

Input parameters:

- `prompt` (string, required): Follow-up message for the existing session.
- `timeout_s` (integer): Max seconds to wait for codex to complete. Default 180.
- `watch` (boolean): If true, open the live "watch" view streaming codex's steps as it    works (same viewer as codex_ask). Default false.
- `workspace`: Working root used by the prior session. Defaults to the server cwd.

Output parameters:

- `result` (string)

### `codex_status` (~144 tokens)

Codex bridge diagnostics

Report diagnostics for the Codex bridge setup (spends no quota).

Reports the bridge's own version and whether a newer release is available
(best-effort GitHub check; honors AGY_BRIDGE_NO_UPDATE_CHECK) — the same
update notice antigravity_status shows, so a Codex-only install still surfaces
it — then checks whether codex is on PATH (and its version), whether you're
logged in (`codex login status` — no model call, no quota), where codex stores
its sessions, and how many workspace sessions are pinned this run. Use this to
debug "codex not found" or auth errors before spending quota.

Output parameters:

- `result` (string)

### `copilot_ask` (~428 tokens)

Ask GitHub Copilot (new session)

Ask the GitHub Copilot CLI (`copilot -p`) a question or task in a NEW session.

Uses your existing Copilot login (OS credential store, or a
COPILOT_GITHUB_TOKEN/GH_TOKEN/GITHUB_TOKEN env var — see `copilot_status`).
Returns the agent's final message, read straight from stdout (the CLI's `-s`
silent mode; no scraping). Copilot is a capable agentic coder — good for real
code/repo work; point `workspace` at a project dir for context-aware answers.

Input parameters:

- `model`: Optional model override (`--model`). Use "auto" to let Copilot pick.    Which ids work is ACCOUNT-DEPENDENT and copilot exposes no    non-interactive list, so the bridge cannot validate this the way…
- `prompt` (string, required): Question or instruction for Copilot.
- `sandbox` (string): Permission policy (maps to copilot's tool/path flags):      "read-only" (default — best-effort: denies the local write/shell      tools; NOT an OS sandbox, so unlike codex it is not a hard      bound…
- `timeout_s` (integer): Max seconds to wait for copilot to complete. Default 180.        (Copilot's reasoning models can be slow; raise this if needed.)
- `watch` (boolean): If true, open a live "watch" view streaming copilot's steps from its    `--output-format json` event stream. Same final text is returned.    Best-effort. Default false.
- `workspace`: Working root for the session (`-C`). Defaults to the server cwd.

Output parameters:

- `result` (string)

### `copilot_continue` (~242 tokens)

Continue GitHub Copilot session

Continue the Copilot session rooted at this workspace (resumes its `--session-id`).

Resumes the exact session id the bridge set on the last copilot_ask in this
workspace, falling back to the newest on-disk session whose recorded cwd
matches (so it still works after a server restart). Unlike codex_continue,
copilot re-applies permission flags on every call, so `sandbox` takes effect
here too — e.g. analyze read-only with copilot_ask, then continue with
"workspace-write" to apply the fix.

Input parameters:

- `prompt` (string, required): Follow-up message for the existing session.
- `sandbox` (string): Permission policy for THIS turn (default "read-only"). Same values      and caveats as copilot_ask.
- `timeout_s` (integer): Max seconds to wait for copilot to complete. Default 180.
- `watch` (boolean): If true, open the live "watch" view streaming copilot's steps    (same viewer as copilot_ask). Default false.
- `workspace`: Working root used by the prior session. Defaults to the server cwd.

Output parameters:

- `result` (string)

### `copilot_status` (~170 tokens)

Copilot bridge diagnostics

Report diagnostics for the Copilot bridge setup (spends no quota).

Reports the bridge's own version and whether a newer release is available
(best-effort GitHub check; honors AGY_BRIDGE_NO_UPDATE_CHECK) — the same
update notice antigravity_status shows, so a Copilot-only install still
surfaces it — then checks whether copilot is on PATH (and its version), an auth
hint (copilot has no `login status` command, so this is best-effort — an env
token is reported when set, otherwise login via the credential store is
assumed and unverified), where copilot stores session state, and how many
workspace sessions are pinned this run. Use this to debug "copilot not found"
or auth errors before a call.

Output parameters:

- `result` (string)

### `cursor_ask` (~435 tokens)

Ask Cursor (new chat)

Ask the Cursor CLI (`cursor-agent -p`) a question or task in a NEW chat.

Uses your existing Cursor login (OS credential store, or a CURSOR_API_KEY env
var — see `cursor_status`). Returns the agent's final message, read straight
from stdout (no scraping). Cursor is a capable agentic coder with a wide model
menu (GPT / Claude / Grok / Composer); point `workspace` at a project dir for
context-aware answers.

Input parameters:

- `model`: Optional model override (`--model`, e.g. "auto", "gpt-5.2",    "claude-opus-4-8-high", "composer-2.5"); validated against    `cursor-agent models` and rejected on a typo. cursor bakes the effort    a…
- `prompt` (string, required): Question or instruction for Cursor.
- `sandbox` (string): Permission policy (maps to cursor's mode/force flags):      "read-only" (default — `--mode ask`: agent-enforced, no file/shell      edits; NOT an OS sandbox, so unlike codex it is not a hard      bou…
- `timeout_s` (integer): Max seconds to wait for cursor to complete. Default 180.
- `watch` (boolean): If true, open a live "watch" view streaming cursor's steps from its    `--output-format stream-json` event stream. Same final text is    returned. Best-effort. Default false.
- `workspace`: Working root for the chat (`--workspace`). Defaults to the server cwd.

Output parameters:

- `result` (string)

### `cursor_continue` (~223 tokens)

Continue Cursor chat

Continue the Cursor chat rooted at this workspace (resumes its chat id).

Resumes the exact chat id the bridge minted on the last cursor_ask in this
workspace, falling back to the newest on-disk chat whose recorded cwd matches
(so it still works after a server restart). cursor applies permission flags per
invocation, so `sandbox` takes effect here too — e.g. analyze read-only with
cursor_ask, then continue with "workspace-write" to apply the fix.

Input parameters:

- `prompt` (string, required): Follow-up message for the existing chat.
- `sandbox` (string): Permission policy for THIS turn (default "read-only"). Same values      and caveats as cursor_ask.
- `timeout_s` (integer): Max seconds to wait for cursor to complete. Default 180.
- `watch` (boolean): If true, open the live "watch" view streaming cursor's steps    (same viewer as cursor_ask). Default false.
- `workspace`: Working root used by the prior chat. Defaults to the server cwd.

Output parameters:

- `result` (string)

### `cursor_status` (~119 tokens)

Cursor bridge diagnostics

Report diagnostics for the Cursor bridge setup (spends no quota).

Reports the bridge's own version and whether a newer release is available
(best-effort GitHub check; honors AGY_BRIDGE_NO_UPDATE_CHECK) — the same
update notice antigravity_status shows, so a Cursor-only install still surfaces
it — then checks whether cursor-agent is found (and its version), whether
you're logged in (`cursor-agent status`), and where cursor stores its chats.
Use this to debug "cursor not found" or auth errors before spending quota.

Output parameters:

- `result` (string)

### `grok_ask` (~476 tokens)

Ask Grok Build (new session) [experimental]

Ask Grok Build (`grok -p`) a question or task in a NEW session. EXPERIMENTAL.

⚠️ Community-verified only: this bridge has never completed an authenticated
round-trip, because the author has no Grok subscription. Its flags are verified
against grok 1.0.3, but the answer path is not. If it misbehaves, say so rather
than working around it — and please report it.

Needs a SuperGrok / X Premium+ login (`grok login`) or an XAI_API_KEY env var;
run `grok_status` first to check. Returns the agent's final message, read from
grok's `--output-format json` result. Point `workspace` at a project dir for
context-aware answers.

Input parameters:

- `model`: Optional model override (`-m`, e.g. "grok-4.5"); validated against    `grok models` and rejected on a typo. Omit to use grok's default.
- `prompt` (string, required): Question or instruction for Grok.
- `sandbox` (string): Permission policy (maps to grok's `--sandbox` profile plus a tool      allowlist): "read-only" (default — the `read-only` profile, no      write/shell tools, no subagents), "workspace-write" (the…
- `timeout_s` (integer): Max seconds to wait for grok to complete. Default 180.
- `watch` (boolean): If true, open a live "watch" view streaming grok's steps from its    `--output-format streaming-json` event stream. Same final text is    returned. Best-effort. Default false.
- `workspace`: Working root (`--cwd`). Defaults to the server cwd.

Output parameters:

- `result` (string)

### `grok_continue` (~260 tokens)

Continue Grok Build session [experimental]

Continue the Grok session rooted at this workspace. EXPERIMENTAL.

Resumes the exact session id grok returned on the last grok_ask in this
workspace (`-r <id>`), falling back to grok's own "most recent session for this
cwd" (`-c`) when that in-memory pin is gone — so it still works after a server
restart. grok applies permission flags per invocation, so `sandbox` takes effect
here too: analyze read-only with grok_ask, then continue with "workspace-write"
to apply the fix. Same experimental caveat and auth requirement as grok_ask.

Input parameters:

- `prompt` (string, required): Follow-up message for the existing session.
- `sandbox` (string): Permission policy for THIS turn (default "read-only"). Same values      and platform caveats as grok_ask.
- `timeout_s` (integer): Max seconds to wait for grok to complete. Default 180.
- `watch` (boolean): If true, open the live "watch" view streaming grok's steps    (same viewer as grok_ask). Default false.
- `workspace`: Working root used by the prior session. Defaults to the server cwd.

Output parameters:

- `result` (string)

### `grok_status` (~162 tokens)

Grok bridge diagnostics

Report diagnostics for the Grok Build bridge setup (spends no quota).

Reports the bridge's own version and any newer release (the same update notice
antigravity_status shows), then whether `grok` is found (and its version),
whether you're authenticated, which models it offers, and where grok keeps its
data. Auth and the model list both come from `grok models`, which answers even
when logged out — so this is cheap and safe to call first.

Use this to debug "grok not found" or auth errors before spending quota. This
backend is EXPERIMENTAL and unverified end-to-end, so a green status here means
the setup looks right, not that a live answer has ever been confirmed.

Output parameters:

- `result` (string)

### `kimi_ask` (~288 tokens)

Ask Kimi (new session) [experimental]

Ask Kimi Code (`kimi -p`) a question or task in a NEW session. EXPERIMENTAL.

⚠️ Community-verified only — built without a Kimi account, so no authenticated
round-trip has ever run and the author cannot verify it. It won't answer until
you authenticate: run `kimi login` (device-code) or put an API key in
\~/.kimi-code/config.toml, then check `kimi_status`. Returns the agent's final
message, read straight from stdout. Kimi Code is Moonshot's terminal coding
agent (Kimi K2 family); point `workspace` at a project dir for context-aware
answers.

Kimi print mode has NO sandbox and auto-executes every tool call (like
antigravity), so run it only with trusted prompts on trusted content.

Input parameters:

- `model`: Optional model alias (`-m`, from ~/.kimi-code/config.toml); omit to    use config's default_model. Not validated up front (Kimi has no    `models` list), so a bad alias surfaces as Kimi's own run-tim…
- `prompt` (string, required): Question or instruction for Kimi.
- `timeout_s` (integer): Max seconds to wait for kimi to complete. Default 180.
- `workspace`: Working root (kimi's cwd). Defaults to the server cwd.

Output parameters:

- `result` (string)

### `kimi_continue` (~142 tokens)

Continue Kimi session [experimental]

Continue the Kimi session rooted at this workspace (`kimi -c`). EXPERIMENTAL.

Resumes the previous Kimi session for this workspace via `-c/--continue` — Kimi
scopes sessions per working directory, so there's no id to track. Errors if no
prior kimi_ask ran in this workspace. Same experimental caveat and auth
requirement as kimi_ask.

Input parameters:

- `prompt` (string, required): Follow-up message for the existing session.
- `timeout_s` (integer): Max seconds to wait for kimi to complete. Default 180.
- `workspace`: Working root used by the prior session. Defaults to the server cwd.

Output parameters:

- `result` (string)

### `kimi_status` (~128 tokens)

Kimi bridge diagnostics

Report diagnostics for the Kimi bridge setup (spends no quota). EXPERIMENTAL.

Reports the bridge's own version and any newer release (same update notice
antigravity_status shows), then checks whether `kimi` is found (and its
version), whether a provider is configured (`kimi provider list` — the auth
proxy, since Kimi needs `kimi login` or an API key in config.toml), and where
Kimi stores its data. This backend is unverified, so expect the auth row to say
"no providers configured" until you log in.

Output parameters:

- `result` (string)

### `opencode_ask` (~475 tokens)

Ask opencode (new session)

Ask opencode (`opencode run`) a question or task in a NEW session.

The one backend here that needs NO subscription: opencode's own free hosted
models (`opencode/*-free`, see `opencode models`) answer with zero credentials
configured, so this works on a machine that has never logged in to anything.
Add a key with `opencode auth login` for Claude/GPT-class models. Returns the
agent's final message, reconstructed from opencode's `--format json` events.
Point `workspace` at a project dir for context-aware answers.

⚠️ The free models are SLOW (queue-scheduled — a one-word answer has taken
minutes), which is why timeout_s defaults to 300 here. Prefer a configured
paid model for anything long, and don't mistake slowness for a hang.

Input parameters:

- `model`: Optional model id (`-m`, "provider/model" — e.g.    "opencode/nemotron-3.5-lightning-free"); validated against    `opencode models` and rejected on a typo. Omit for opencode's    configured default.
- `prompt` (string, required): Question or instruction for opencode.
- `sandbox` (string): Permission policy, applied via opencode's OPENCODE_PERMISSION and      enforced by the agent on every platform alike: "read-only"      (default — no edit/bash/subagent/network tools, `.env` files…
- `timeout_s` (integer): Max seconds to wait for opencode to complete. Default 300.
- `watch` (boolean): If true, open a live "watch" view streaming opencode's steps from    the same `--format json` event stream. Same final text is returned.    Best-effort. Default false.
- `workspace`: Working root (`--dir`). Defaults to the server cwd.

Output parameters:

- `result` (string)

### `opencode_continue` (~279 tokens)

Continue opencode session

Continue the opencode session rooted at this workspace.

Resumes the exact session id opencode reported on the last opencode_ask in this
workspace (`-s <id>`), falling back to opencode's own "most recent session for
this directory" (`-c`) when that in-memory pin is gone — so it still works after
a server restart. Session scoping is per directory (verified live: the same
\`-c` from a different directory starts a fresh session), so pass the same
\`workspace` you asked in. The permission policy applies per invocation, so
\`sandbox` takes effect here too: analyze read-only with opencode_ask, then
continue with "workspace-write" to apply the fix.

Input parameters:

- `prompt` (string, required): Follow-up message for the existing session.
- `sandbox` (string): Permission policy for THIS turn (default "read-only"). Same values      and caveats as opencode_ask.
- `timeout_s` (integer): Max seconds to wait for opencode to complete. Default 300.
- `watch` (boolean): If true, open the live "watch" view streaming opencode's steps    (same viewer as opencode_ask). Default false.
- `workspace`: Working root used by the prior session. Defaults to the server cwd.

Output parameters:

- `result` (string)

### `opencode_status` (~118 tokens)

opencode bridge diagnostics

Report diagnostics for the opencode bridge setup (spends no quota).

Reports the bridge's own version and any newer release (same update notice
antigravity_status shows), then checks whether `opencode` is found (and its
version), how many provider credentials are configured, which model ids are
available, and where opencode keeps its data. "0 credentials" is NOT a failure
here — opencode's free `opencode/*` models still answer — so that row stays ok
as long as models are listed.

Output parameters:

- `result` (string)

### `muse_ask` (~402 tokens)

Ask Muse Code (new session) [experimental]

Ask Meta's Muse Code (`muse exec`) a question or task in a NEW session. EXPERIMENTAL.

⚠️ The real model has never answered through this bridge — the author has no
Muse plan. Muse's built-in offline `echo` provider verified everything else
end to end (argv, event stream, answer, session resume), so a failure here is
most likely auth or the model itself. If it misbehaves, say so plainly and
please report it.

Needs a Muse Code plan (`muse login`) or a META_API_KEY; run `muse_status`
first. Returns the agent's final message (the `run_terminal` event of
\`muse exec --json`). Point `workspace` at a project dir for repo context.

Input parameters:

- `model`: Optional model id (`--model`, e.g. "muse-spark-1.3"). Muse accepts    any id, so this is not validated. Omit for muse's default.
- `prompt` (string, required): Question or instruction for Muse. Passed in a file, never argv.
- `sandbox` (string): "read-only" (default — muse's write, shell and web tools switched      off, so it can only read and answer; holds on every OS),      "workspace-write" (shell runs inside muse's OS sandbox, network…
- `timeout_s` (integer): Max seconds to wait for muse to complete. Default 180.
- `watch` (boolean): If true, open a live "watch" view of muse's task stream. Same final    text is returned. Best-effort. Default false.
- `workspace`: Working root (`--workspace`). Defaults to the server cwd.

Output parameters:

- `result` (string)

### `muse_continue` (~224 tokens)

Continue Muse Code session [experimental]

Continue the Muse session rooted at this workspace. EXPERIMENTAL.

Resumes the exact session the last muse_ask in this workspace created (the
bridge names each session itself with `--session-id`). After a server restart
it falls back to muse's own record of the workspace's most recent session
(`muse export --last`); with no session there at all it errors rather than
silently starting a fresh one. Muse applies safety flags per run, so `sandbox`
takes effect here too. Same experimental caveat and auth needs as muse_ask.

Input parameters:

- `prompt` (string, required): Follow-up message for the existing session.
- `sandbox` (string): Policy for THIS turn (default "read-only"); same values as muse_ask.
- `timeout_s` (integer): Max seconds to wait for muse to complete. Default 180.
- `watch` (boolean): If true, open the live "watch" view (same viewer as muse_ask).
- `workspace`: Working root used by the prior session. Defaults to the server cwd.

Output parameters:

- `result` (string)

### `muse_status` (~138 tokens)

Muse bridge diagnostics

Report diagnostics for the Muse Code bridge setup (spends no quota).

Reports the bridge's own version and any newer release, then whether `muse` is
found (and which binary the bridge runs), whether credentials are present
(META_API_KEY or a `muse login`), any cached model catalog, the Windows OS
sandbox state, and where muse keeps its data. Muse has no free auth probe, so a
green auth row means credentials exist, not that they are still valid. This
backend is EXPERIMENTAL: green here means the setup looks right, not that a real
answer has ever been confirmed.

Output parameters:

- `result` (string)

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/sinantufekci-agent-intern/agent-intern#diagnostics

## Score history

- 2026-09-25: 69
- 2026-09-24: 54

## Common questions

### What is the Agent Intern MCP server?

Agent Intern is an MCP server listed in the public MCP registry as io.github.SinanTufekci/agent-intern. Delegate from Claude Code to Gemini, Codex, Copilot, Cursor and opencode CLIs as sub-agents. This page covers its PyPI package (agent-intern).

### Is the Agent Intern MCP server safe to use?

Agent Intern scores 69 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Agent Intern MCP server expose?

Agent Intern exposes 29 tools: antigravity_ask, antigravity_continue, antigravity_image, agent_swarm, preset_swarm, and 24 more. Their descriptions and schemas cost roughly 9,106 tokens of context every time the server is loaded.

### Is the Agent Intern MCP server still maintained?

Agent Intern is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Agent Intern MCP server under?

Agent Intern declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/agent-intern/
- Socket report: https://socket.dev/pypi/package/agent-intern
- Repository: https://github.com/SinanTufekci/agent-intern
- Changelog RSS feed: https://verifymcp.io/servers/sinantufekci-agent-intern/agent-intern.xml
- Changelog JSON feed: https://verifymcp.io/servers/sinantufekci-agent-intern/agent-intern.json
- HTML version of this page: https://verifymcp.io/servers/sinantufekci-agent-intern/agent-intern