Agent Intern
PYPI · AGENT-INTERN · SCANNED SEP 25
Delegate from Claude Code to Gemini, Codex, Copilot, Cursor and opencode CLIs as sub-agents.
Available components
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. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs setuptools.build_meta at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 1 of 14 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency48
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 0 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability64
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 29 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 30 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
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.
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.
pypi · agent-intern
claude mcp add sinantufekci-agent-intern -- uvx agent-intern
{
"mcpServers": {
"sinantufekci-agent-intern": {
"command": "uvx",
"args": [
"agent-intern"
]
}
}
} {
"servers": {
"sinantufekci-agent-intern": {
"command": "uvx",
"args": [
"agent-intern"
]
}
}
} codex mcp add sinantufekci-agent-intern -- uvx agent-intern
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"sinantufekci-agent-intern": {
"type": "local",
"command": [
"uvx",
"agent-intern"
],
"enabled": true
}
}
} openclaw mcp add sinantufekci-agent-intern --command uvx --arg agent-intern
mcp_servers:
sinantufekci-agent-intern:
command: "uvx"
args: ["agent-intern"] {
"McpServers": {
"sinantufekci-agent-intern": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"agent-intern"
]
}
}
} assistant mcp add sinantufekci-agent-intern -t stdio -c uvx -a agent-intern
{
"mcpServers": {
"sinantufekci-agent-intern": {
"command": "uvx",
"args": [
"agent-intern"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 +15
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 24 Sept 26 54
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Sept 2026 · Analysed pypi/agent-intern@0.32.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | setuptools.build_meta |
Background: Why install scripts are a supply-chain risk →
Dependencies 14 packages
| Packages resolved | 14 |
|---|---|
| Stale | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
agent_swarm Agent swarm (mixed Antigravity + Codex + Copilot + Cursor + …, parallel) ~825
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
antigravity_ask Ask Antigravity (new conversation) ~1,156
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
antigravity_continue Continue Antigravity conversation ~462
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
antigravity_image Generate an image with Antigravity ~278
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).
| Name | Type | Req | Description |
|---|---|---|---|
| output_path | – | – | Where to save. Absolute, or relative to `workspace`. If omitted, a timestamped name under `workspace` is used. |
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
antigravity_image_swarm Generate several images in parallel ~246
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
antigravity_status agy bridge diagnostics ~190
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
codex_ask Ask Codex (new session) ~497
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.
| Name | Type | Req | Description |
|---|---|---|---|
| model | – | – | Optional model override (`-m`); omit to use codex's configured default. |
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
codex_continue Continue Codex session ~184
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.
| Name | Type | Req | Description |
|---|---|---|---|
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
codex_status Codex bridge diagnostics ~144
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
copilot_ask Ask GitHub Copilot (new session) ~428
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
copilot_continue Continue GitHub Copilot session ~242
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.
| Name | Type | Req | Description |
|---|---|---|---|
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
copilot_status Copilot bridge diagnostics ~170
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
cursor_ask Ask Cursor (new chat) ~435
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
cursor_continue Continue Cursor chat ~223
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.
| Name | Type | Req | Description |
|---|---|---|---|
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
cursor_status Cursor bridge diagnostics ~119
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
grok_ask Ask Grok Build (new session) [experimental] ~476
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
grok_continue Continue Grok Build session [experimental] ~260
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.
| Name | Type | Req | Description |
|---|---|---|---|
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
grok_status Grok bridge diagnostics ~162
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
kimi_ask Ask Kimi (new session) [experimental] ~288
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
kimi_continue Continue Kimi session [experimental] ~142
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.
| Name | Type | Req | Description |
|---|---|---|---|
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
kimi_status Kimi bridge diagnostics ~128
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
muse_ask Ask Muse Code (new session) [experimental] ~402
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
muse_continue Continue Muse Code session [experimental] ~224
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.
| Name | Type | Req | Description |
|---|---|---|---|
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
muse_status Muse bridge diagnostics ~138
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
opencode_ask Ask opencode (new session) ~475
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
opencode_continue Continue opencode session ~279
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.
| Name | Type | Req | Description |
|---|---|---|---|
| prompt | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
opencode_status opencode bridge diagnostics ~118
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
preset_swarm Preset swarm (jury / research / red team / council) ~248
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.
| Name | Type | Req | Description |
|---|---|---|---|
| material | string | yes | The text the panel works on, in full. |
| max_concurrency | integer | – | Members running at once (default 4). |
| preset | string | yes | 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
swarm_presets Swarm presets (list, or show one to customise) ~167
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
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.