▸ The claude --visit terminal above shows the intended UX. What ships today is the portal.visit() TS SDK + visit-portal CLI, which produce this exact flow in three lines. Client-side integration into Claude Code is an SDK proposal, not an existing flag.
Every connected MCP server injects its full tool schema into every turn. Measured on Claude Sonnet 4.5 and Opus 4.5 via Anthropic's count_tokens API: 10 tools = 1,956 tokens. 100 tools = 13,929. 400 tools = 54,677. Projected at 1,000 tools: ≈137,000 — 69% of Sonnet's 200k window, gone before the user types a word.
Scalekit's controlled benchmark on Claude Sonnet 4 across 75 identical tasks: MCP cost 4× to 32× more tokens than lightweight alternatives. A single repo-language check burned 44,026 tokens via MCP vs 1,365 via CLI.
Real Claude Code user, real session: 82,000 tokens — 41% of the window — consumed by tool definitions on an empty conversation. Our bench (below) measures the same shape of waste across a reproducible 48-cell matrix.
Submission-day snapshot of what the repo produces. Every card is traceable to a file or a commit. If you clone the repo and run pnpm -r test && bash scripts/demo.sh && pnpm --filter @visitportal/bench bench, every number below is reproducible on your box in under ninety seconds.
▸ As of 2026-04-19, one commit per phase on main: c82c882 · 98ec8d9 · d1c40ba · 272cd53 · f6c8b32 · 8f1c997. Full phase table in docs/status.md.
▸ Cost math: Sonnet 4.5 input ($3/M tokens), 100 turns/day, 30 days. 100-tool MCP burns ~$125/user/mo of pure schema overhead; Portal equivalent ~$1.55. Projected 1,000-tool MCP ≈ $1,230/user/mo. Scale across an enterprise fleet and the numbers become structural.
| MCP (today) | Portal (v0.1) | |
|---|---|---|
| When tools load | Every turn, every message, forever | Once per visit, then dropped |
| Where they live | Permanently in context window | In context only during the visit |
| Cost shape | Fixed tax on every message | One-time read, fire-and-forget |
| Visitor install | Client must pre-configure server | None. Any LLM client visits cold |
| Scaling ceiling | ~1,500 tools saturates Sonnet's 200k window (projected from measured linear fit) | Unbounded — 172 tokens per visit, flat |
| Residue after use | Still loaded, still billed | Gone. No trace. Next turn free. |
| Monetization surface | None per use | Every visit = billable event |
Portal is deliberately small. The base spec fits on a napkin. Anything a provider already has — an MCP server, a REST API, a function list — can be wrapped in an afternoon.
# GET /portal — the manifest { "portal_version": "0.1", "name": "Star Screener", "brief": "I screen trending GitHub repos. Ask for top gainers, keyword matches, maintainer profiles.", "tools": [ { "name": "top_gainers", "params": { "limit": "number" } } ], "call_endpoint": "https://demo.visitportal.dev/portal/call", "auth": "none", // optional: api_key, erc8004 "pricing": { "model": "free" } // optional: x402 micropayment } # POST /portal/call — execute a tool → request: { "tool": "top_gainers", "params": { "limit": 5 } } ← response: { "ok": true, "result": { ... } } # That's the whole spec. Everything else is optional.
No runtime, no daemon, no registration. The visitor does HTTP; the provider does HTTP. Everything between the first GET and the final POST is the manifest — in context during the visit, gone after.
The agent-interop space is consolidating. Portal slots in as the lightweight entry point — everything else upgrades from here.
The scaling wall is not abstract — it hits different roles differently. Portal's unit economics change the answer for each.
| Persona | Pain today | With Portal |
|---|---|---|
| Claude Code power user | 82k tokens burned on preloaded tool schemas every turn — 41% of Sonnet's window gone before typing. | Visits exactly what's needed, 172 tokens per visit, nothing carried forward. |
| Service provider | No low-friction way to expose tools to agents. An MCP server is an afternoon of protocol plumbing plus ongoing maintenance. | Two HTTP endpoints, one manifest, ship in an hour. Any existing REST/GraphQL service is wrappable. |
| Enterprise fleet | 1,000-tool MCP deployment at 100 turns/user/day = projected ~$1,230/user/mo in pure schema overhead on Sonnet. | Same fleet on Portal: ~$1.55/user/mo. The 99.9% savings compounds across seats. |
▸ Enterprise math: Sonnet 4.5 input $3/M · 100 turns/day · 30 days · 1,000 tools projected at ~137k tokens per turn via the linear fit of measured counts. Portal's 172 tokens per visit are measured directly. Re-derive: packages/bench/results/tokens-matrix-v1.md.
MCP tools are installed once and used forever — there's no natural moment to charge, gate, or monetize. Portal's visit model creates that moment on every interaction.
Every visit is a billable event. x402 micropayments per call. The Stripe-of-agents primitive.
$0.001/ callManifest exposes 3 free tools openly; 10 premium tools revealed after payment or identity check.
3 → 10toolsVisitor buys a specialized skill for this session only. Uses it. Leaves. No install, no subscription.
1visitERC-8004 verified agents get writes; anonymous visitors get reads only. Trust scales with the visit.
verified→ writesA published v0.1 spec. A reference Portal at a live service. A portal.visit() SDK in TypeScript and Python. A Claude Code demo where the agent visits a Portal cold, executes real work, and leaves — all in under ten seconds with zero configuration.
A reproducible MCP-vs-Portal benchmark suite so every claim on this page is independently verifiable. Ten popular MCP servers Portal-wrapped as proof of compatibility. A public directory so Claude Code users can discover Portals the way they already discover repos.
Built by operators, not researchers — the team behind ClawPulse (streaming intelligence for agents), AGNT (agent marketplace), and the AGP envelope. We've been shipping this category for a year. Portal is the piece that makes the rest of the stack compounding.