mcp-agent

By default an mcp-agent app runs with the developer's own authority: LLM API keys come from env vars or a plaintext secrets file, and stdio MCP servers are launched as the same OS user. The one narrowing step is that stdio servers get a minimal default environment plus their configured variables rather than the full parent environment. For HTTP MCP servers the framework offers an opt-in OAuth client whose tokens are cached per user identity and per requested scope set, which is a real per-capability scoping primitive but is off unless configured per server.

The framework has no approval gate for tool calls. The hook that runs before each tool call simply returns the request unchanged unless a developer subclasses it, and the human-input tool is something the model chooses to call, not a checkpoint on actions. The only built-in human approval covers MCP sampling requests, not tool execution. In the scaffolded default config the agent can overwrite project files and fetch arbitrary URLs with no human in the loop.

Tool arguments are passed through to MCP servers without framework-side validation; only local Python function tools get typed pydantic parsing. Enforcement of the per-server allowed_tools setting does not cover every path. The default template enables filesystem write and unrestricted web fetch.

mcp-agent has no isolation mechanism. Configured stdio MCP servers, including the default filesystem server launched with npx, run as ordinary subprocesses of the same OS user, and local function tools run in the agent's own process. Any code those paths execute can reach the user's home directory, network, and the project's secrets file.

Tool and MCP results are appended to the conversation as ordinary tool messages with no untrusted marking, and nothing in the framework changes what the agent may do after reading external content. In the scaffolded default, one session combines web fetch (untrusted input and an exfiltration channel), the project directory including the secrets file, and file write. A successful prompt injection can therefore both leak keys and overwrite files without any human involvement.

Conversation memory is in-process and session-scoped, but configuration is not. At startup the app searches the current directory and every parent for its config and secrets files, reads a .env file from the working directory (which can set values such as the OpenAI base URL), and auto-loads sub-agent definitions from .claude/agents and .mcp-agent/agents in the working directory. Those definition files can name Python callables, which the loader imports by module name, so files in the workspace can trigger code import without any trust prompt. Because the default filesystem server is rooted at the same directory, the agent itself can write these files for the next run.

MCP servers are whatever the config names, and the scaffolded template launches them with npx -y and uvx with no version pins, so the latest package is fetched and executed at each launch. There is no integrity check or re-approval when a server changes. stdio servers do get a reduced default environment, but they run as the same user, and function references in sub-agent spec files are imported into the agent's own process.

API keys come from env vars or a plaintext, gitignored secrets file that sits in the project directory. The log serializer masks values under sensitive-looking keys, but leaves the first ten characters visible, and an environment variable turns masking off entirely. Usage telemetry is flagged on but currently sends nothing. The biggest problem is placement: the default filesystem server is rooted at the same directory as the secrets file, so the model can read the long-lived keys.

By default the aggregator logs each MCP tool call at info level with tool, server, and agent names but not the arguments, and the scaffolded config writes these logs to a file inside the project directory that the agent's own filesystem tool can edit. Logs are batched and flushed every two seconds. Opt-in OpenTelemetry tracing records tool arguments and results under agent-named spans and can export over OTLP, which is a much better record but is off by default.

Each LLM generate call is limited to 10 tool-use iterations and 2048 output tokens per completion. There is no wall-clock limit, no cost cap, and tool calls have no timeout by default, so a hanging MCP server blocks indefinitely. Orchestrator, router, and swarm patterns create sub-agents that each get their own fresh iteration budget. A budgeted deep-orchestrator workflow exists but applies only to that workflow.