'%20stroke='url(%23em)'/%3e%3cellipse%20cx='30'%20cy='34'%20rx='26'%20ry='20'%20fill='url(%23gm)'/%3e%3cpath%20d='M12.5%2013.00L52.5%2021.74L52.5%2024.33L12.5%2017.60Z'%20fill='url(%23lm)'/%3e%3crect%20x='14.20'%20y='19.29'%20width='6.60'%20height='28.93'%20rx='1.45'%20fill='url(%23cm0)'/%3e%3crect%20x='27.00'%20y='21.24'%20width='5.60'%20height='24.81'%20rx='1.23'%20fill='url(%23cm1)'/%3e%3crect%20x='37.60'%20y='22.85'%20width='4.70'%20height='21.42'%20rx='1.03'%20fill='url(%23cm2)'/%3e%3crect%20x='46.60'%20y='24.22'%20width='4.00'%20height='18.53'%20rx='0.88'%20fill='url(%23cm3)'/%3e%3cpath%20d='M12.5%2050.00L52.5%2042.57L52.5%2044.26L12.5%2053.00Z'%20fill='%237fa3ff'%20opacity='.75'/%3e%3c/svg%3e)
PorticolMCP
An MCP server lets an MCP client, such as Claude Code, use a team's collections through Porticol: search the workspace, read requests and examples, list environments, send and run requests, with secrets resolved inside Porticol and masked before they leave. Two transports serve the one tool table: standard input and output on the machine, and streamable HTTP on a server. There are no server-sent events and no server-initiated messages.
Tools
| Tool | Scope | What it does |
|---|---|---|
search |
Read | Search collections, requests and history for a query |
read |
Read | Read a collection with its requests and examples, or one request of it |
environments |
Read | List the environments, or read one by id |
send |
Read | Send a request and return what came back |
run |
Read | Run a collection and wait for it, returning the finished run |
history |
Read | List recent sends, or read one by id |
import_openapi |
Read | Preview an OpenAPI document as a collection, without importing it |
create_request |
Write | Add a request or folder to a collection |
update_request |
Write | Replace what a request or folder holds |
import_openapi only previews; bringing the collection into the workspace stays
a person's decision. run starts the run, waits for it, and returns it finished;
when the wait runs out it returns the run still going instead.
Scopes and guardrails
Read-only by default. The two write tools stay off until the caller holds the write scope, and a call outside the scope is refused.
Secrets resolved inside Porticol never leave it in the clear: every tool result that can carry a secret is masked with the same redaction history relies on, over every secret value the workspace holds.
An environment marked protected refuses an agent's send until a person allows
it. The refused call answers needs_confirmation with the key to allow: a
person allows it the way they allow any send, and the agent calls send again.
An agent's send is recorded with the client's name.
Standard input and output
porticol-cli mcp serves the workspace on the machine:
porticol-cli mcp [--data-dir <path>] [--write]
It speaks MCP JSON-RPC over standard input and output: initialize,
notifications/initialized, tools/list, tools/call and ping. Without
--write the write tools are refused. The workspace served is --data-dir,
PORTICOL_DATA_DIR, or the desktop's data folder. Secret values live in the
machine's keychain under the desktop; a workspace served here resolves the
secrets created through it.
Streamable HTTP
POST /api/v1/mcp serves the same tools on a server, with the API token's
scope: a read-only token lists the read tools only, and collection:write
adds the two write tools. It answers initialize, tools/list and tools/call
as plain JSON responses. Every tools/call writes one audit entry named
mcp.<tool> with the token's id. A command that only runs beside the user, such
as sending, is refused over HTTP the way /api/v1/call refuses it; agents send
through the standard input transport beside the workspace.