LIVE PORTAL OPEN STANDARD · v0.1.11 docs bench directory github↗
BUILT WITH OPUS 4.7 · HACKATHON ENTRY APR 2026
Portal · v0.1.11 · Apache-2.0

If your service has a URL,
an agent can visit it.

Portal is the minimal HTTP contract for agent-accessible services. Two endpoints. No install. No SDK required.
two curl commands · www.visitportal.dev
~ # 1. Discover — read the manifest
~ curl https://www.visitportal.dev/portal-static-example.json
200 OK · returns { name, brief, tools[], call_endpoint }
~ # 2. Call — execute a tool
~ curl -X POST https://www.visitportal.dev/api/portal-static-example/call \
    -H 'content-type: application/json' \
    -d '{"tool":"posts","params":{"limit":3}}'
200 OK · { ok: true, result: [...] }

view docs · view repo · run conformance

01THE SCALING WALL

MCP's success created its next problem.

As the number of connected tools grows, loading all tool definitions upfront and passing intermediate results through the context window slows down agents and increases costs. Once too many servers are connected, tool definitions can consume excessive tokens, reducing agent efficiency. — paraphrased, Anthropic engineering guidance on MCP scaling, 2026

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.

02THE NUMBERS

Context tokens consumed, per turn.

benchmark · mcp-vs-portal.json MEASURING

Schema overhead by tool count

Every message. Whether the agent uses them or not.
MCP · preloaded Portal · on visit
10 tools
1,956tok
172tok
50 tools
7,343tok
172tok
100 tools
13,929tok
172tok
400 tools
54,677tok
172tok
1,000 tools*
~137,000tok
172tok
02bPROOF & POSTURE

What's running, not what's promised.

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.

TESTS
189/189
across spec · provider · visit · cli · bench · mcp-adapter · x402-adapter · reference
pnpm -r test
BENCH CELLS
48
real Anthropic count_tokens · seed 42 · Sonnet + Opus
packages/bench/results/tokens-matrix-v1.json
SDK SIZE
2.25 kB
@visitportal/visit · gzipped · 6.7× under 15 kB ceiling
pnpm --filter @visitportal/visit size
DEMO TIME
7s
boot → manifest → call → conformance → clean shutdown
bash scripts/demo.sh
SPEC SURFACE
2 endpoints
GET /portal · POST /portal/call · one manifest schema
docs/spec-v0.1.11.md
CONFORMANCE
36/36
vectors · ajv ↔ lean validator agree on every one (13 valid + 13 invalid + 10 call pairs)
packages/spec/conformance/vectors.json

As of 2026-04-30 (v0.1.11): five npm packages live (@visitportal/{spec, provider, mcp-adapter, x402-adapter}), end-to-end x402 v2 round-trip production-verified against AISO Sponge gateway. Full phase table in docs/status.md; release notes in CHANGELOG.md.

03THE IMPACT
01
81×
less context tax at
100-tool scale (measured)
02
99.9%
schema-overhead tokens
eliminated at 1k tools
03
0
installs required
on visitor side

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.

04SIDE-BY-SIDE

What changes mechanically.

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
05THE ENTIRE SPEC

Two endpoints. One manifest.

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.

portal.json · v0.1 SPEC · PUBLIC DOMAIN
# 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": "/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.
06THE VISIT

A drop-in in under ten seconds.

01 ARRIVE URL handed in Agent receives a URL. Zero prior config.
02 READ Manifest fetched GET /portal returns name, brief, tools.
03 CALL Tool executed LLM picks, POST /portal/call runs it.
04 USE Result lands Output flows back into context.
05 LEAVE Session ends Manifest drops. Zero residue. Next turn free.
06bTHE WIRE

Two calls. One manifest. Nothing sticks around.

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.

Portal visit sequence diagram Two HTTP calls between an LLM visitor and a provider. GET /portal returns a 172-token manifest. POST /portal/call runs a tool and returns the result. Session ends; manifest is dropped from context; zero residue remains. VISITOR Claude Code · any LLM client PROVIDER your service · two endpoints 1 · ARRIVE GET /portal no body · Accept: application/json 200 OK · manifest (172 tokens) portal_version, name, brief, tools[], call_endpoint 2 · CALL POST /portal/call { tool: "top_gainers", params: { limit: 3 } } 200 OK · result { ok: true, result: [...] } | { ok: false, error, code } 3 · LEAVE session ends · manifest dropped · next turn pays 0 tokens
Rule 1. Everything under /portal/call is stateless. If a tool needs a session, use A2A — it's the next layer up.
Rule 2. The manifest is the contract. If an SDK can validate it against manifest.schema.json, the SDK can call any Portal on the internet.
Rule 3. Base stays neutral. Auth, pricing, identity, registry — all are optional Portal Extensions, never in the base spec.
07POSITIONING

Portal for drive-by visits. MCP for installed tools. A2A for agent coordination.

Three layers, one stack. Portal is not a competitor to MCP or A2A — it's the stateless, zero-install entry point. They compose.

Tier Protocol Use case
1 Portal Drive-by HTTP visits. Stateless. No install.
2 MCP Installed stateful tools.
3 A2A Multi-agent coordination.
The one-liner
If your service has a URL, an agent can visit it.
No install. No SDK. No lock-in.
07bWHO BENEFITS

Three personas. One architecture.

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.

08WHAT PORTAL UNLOCKS

A transaction surface, by construction.

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.

Pay-per-visit

SHIPPED · v0.1.11

Every visit is a billable event. x402 v2 micropayments per call via @visitportal/x402-adapter (on npm). Production-verified against AISO Sponge gateway.

$0.001/ call

Gated tiers

new surface

Manifest exposes 3 free tools openly; 10 premium tools revealed after payment or identity check.

3 → 10tools

Session-scoped skills

new surface

Visitor buys a specialized skill for this session only. Uses it. Leaves. No install, no subscription.

1visit

Identity-gated access

new surface

ERC-8004 verified agents get writes; anonymous visitors get reads only. Trust scales with the visit.

verified→ writes
Pay-per-visit is shipped, not promised. @visitportal/x402-adapter is on npm. PE-002 paid tools are stable. End-to-end x402 v2 round-trip production-verified against the live AISO Sponge gateway: signed EIP-3009 USDC authorization, valid signature, only blocker on test was unfunded testnet balance — the protocol settles.
09WHAT'S SHIPPED

The visitor-side half of the agent-interop story.

Spec v0.1.8 normative. Five npm packages live: @visitportal/spec, @visitportal/provider, @visitportal/mcp-adapter, @visitportal/visit, @visitportal/x402-adapter. Reference Portals run on Hono (trending-demo), Cloudflare Workers (portal-cf-worker), and as a static-fallback Edge function. The Claude Code demo visits cold and leaves in ~7 seconds.

Reproducible MCP-vs-Portal bench (48 cells, real Anthropic count_tokens) so every number on this page is independently re-derivable. End-to-end agent-simulation script drives a real Claude run against the reference Portal. @visitportal/mcp-adapter wraps existing stdio MCP servers; @visitportal/x402-adapter wraps any handler with x402 v2 paid-tool gating in one line.

External integration contracts shipped: AISO Portal Readiness Score (5 × 20-point rubric, normative JSON Schema) and TrendingRepo "Portal Ready" badge (4 states + agent-actions preview). Both are docs-only — base Portal stays neutral and unowned. Architecture overview at docs/architecture-overview.md; one-page spec at docs/spec-v0.1.8.md.