simse extends with tools through MCP (Model Context Protocol). MCP defines how tools are discovered, described, and invoked over stdio or HTTP transports.
simse implements both sides of MCP:
The MCP protocol defines a standard handshake for tool discovery. When simse connects to an MCP server, it:
Tool output is returned to the model, which uses it to continue the response. simse enforces output size limits (50,000 characters by default) and truncates longer outputs.
The MCP server runs as a child process. simse communicates with it over standard input and output. This is the most common transport for local tools:
{
"servers": [
{
"name": "filesystem",
"transport": "stdio",
"command": "npx",
"args": ["@modelcontextprotocol/server-filesystem", "/path/to/project"]
}
]
}
The command field is a single executable; pass everything else as separate entries in args. simse manages the process lifecycle -- starting it on connection, restarting it on failure.
The MCP protocol itself also defines an HTTP transport for servers that run as standalone network services. Server entries in mcp.json configure stdio subprocesses; the command + args form shown above is the configuration simse uses.
simse also exposes its capabilities as an MCP server. Other agents and systems can connect to simse and use:
This makes simse composable with other agent systems and automation pipelines.
Every tool invocation goes through permission checking. The configured permission mode determines what happens:
| Mode | Behavior |
|---|---|
"default" | Ask the user before each tool action |
"acceptEdits" | Auto-approve file edits, ask for other actions |
"plan" | Plan only -- list what tools would do, but do not execute |
"dontAsk" | Auto-approve all tool actions |
Permissions can also be granted per-action during a session with allow once or allow always.