Give each check a specific job
Authentication, resource scopes, profile filtering and engine permissions govern different boundaries. A visible tool name alone is not a grant of permission to execute it.
Selected work
Case study 03 / Connected tools
Useful tools need clear boundaries.
A shared gateway connects agents to separate tools. Identity, access scopes and conversation profiles each answer a different question about what an agent can do.
One request allowed. Another stopped.Try the gateway boundary.Actual gateway responses with fictional local services.MCPOAuthTypeScriptPythonGo
Gateway + permissionsA personal engineering project
A small tool for an everyday question
Which platform?
Trains MCP brings a service’s platform, departure time and status into one answer.
Sample data · 24 May 2026Recorded offline. These are saved examples, not current travel information.
A typeset view of actual recorded tool responses. Selecting a train shows a saved answer; it does not request a new departure time.
See the recorded responses
The calls used the tool’s original synthetic sample data with networking disabled. The exact names, arguments and returned text are retained in the receipt.
Read the original departure board
Departures from **København H** (id 008600626, train, s-tog, metro, letbane): - 2026-05-24 14:32 → 14:39 (+7min) | **IC 123** → Aarhus H | platform **5** (changed from 3) - 2026-05-24 14:35 (on time) | **A** → Hillerød St. | platform **1** - 2026-05-24 14:40 (on time) | **Re 5432** → Nykøbing F. | platform **7** **CANCELLED** - 2026-05-24 14:38 (on time) | **B** → Farum St. | platform **2** - 2026-05-24 14:45 → 14:48 (+3min) | **L 45** → Aalborg | platform **4**
The original board labels the cancelled service’s timestamp “on time” alongside “CANCELLED”. The card gives the cancellation priority. These samples do not establish current service conditions, and the original sample does not provide a working route-planning example.
01The starting point
Every new tool brings an access question.
An agent becomes more useful when it can reach the applications and files involved in a task. Connecting several engines to tools on several machines also brings questions about identity, access and availability.
I built a shared gateway so those questions have a consistent place to be answered. Individual tool servers still own their capabilities, and some depend on another machine being available.
01PanelForgeWeb workspace
02Agent enginesClaude / Codex / OpenCode
03Apple clientConversations on Apple devices
Forge / connected by design
View 01
Start with what a person sees.
PanelForge is the web workspace. The Apple client brings conversations to another screen. Both use the engine services to reach agent runtimes through a shared stream format.
Two ways into the work. A shared engine boundary.
01Agent enginesAgent runtimes
02MCP gatewayA common entry point
03Tool servicesIndependent capabilities
Forge / connected by design
View 02
Let each part do its own job.
Claude, Codex and OpenCode speak through one client stream contract. The MCP gateway connects those engines to separate tool services. A service may live on a different machine.
Shared boundaries make differences easier to handle.
01Caller identityWho is calling?
02Resource accessWhich resources may they use?
03Tool profileWhich tools does the model see?
Forge / distinct permission boundaries
View 03
Give each check a specific job.
Authentication identifies a caller. Resource scopes govern access. Conversation profiles narrow the tools a model can see. These controls govern different boundaries; the engine also enforces its own execution permissions.
A tool appearing in the catalog is not permission to run it.
02What the workflow looks like
A useful path through the product.
- 01
Establish who is calling
Authentication identifies the caller. Ownership rules and scopes govern which resources that caller may access.
- 02
Choose what the conversation can see
A tool profile narrows the catalog visible to the model. That is a separate control from resource access and the engine’s own execution permissions.
- 03
Reach a capability through the gateway
Separate servers provide tools for tasks such as image workflows and canvas editing. Cached descriptions let clients discover them without a fresh handshake with every server.
One request, visible tool activity
From a conversation to playing a track.
This saved showcase turn transfers Spotify playback, sets the volume and plays the requested song. The conversation records the tool calls and their result.
A saved Spotify showcase conversation in the current web interface. Device identifier redacted.Select the image to explore the details.
03Design + engineering
The decisions underneath.
Keep the catalog useful during a failure
The schema cache preserves a server’s last working descriptions if a refresh fails. This prevents a discovery failure from emptying that part of the catalog.
Preserve state where a tool needs it
The gateway gained a stateful proxy path for InfinitySketch, followed by Freeform support. Canvas tools could use the common entry point while retaining their own session requirements.
Explore the individual features
The smaller pieces of this story.
04Selected release history
It got here one decision at a time.
These are historical changes recorded in repository tags. The capture and current-state notes below describe what is being shown here.
A reusable tool catalog
MCP Bridge introduced its schema cache, separating client discovery from the availability of each underlying tool server.
MCP Bridgev1.0.0A common bridge for separate tools
The bridge moved all eleven tool servers onto the same multiplexer, giving separate stdio capabilities a consistent service boundary.
MCP Bridgev3.0.0Connect a native canvas
Freeform joined the gateway’s resources after the stateful InfinitySketch proxy work.
PanelForge MCPv5.10.0Enforce the runtime’s tool ceiling
Codex native tool profiles were validated against the installed catalog and enforced across resumed and forked sessions.
Codex Enginev0.6.28Use the cached handshake
MCP Bridge refused an incompatible stateless discovery path and used the cached handshake instead.
MCP Bridgev3.10.9
About the material shown here
Product views.
Release notes.
Selected screenshots and edited recordings accompany changes checked against repository history through October 2026.
Current product and capture
The gateway gives connected tools a common entry point, with resource scopes, conversation profiles and support for stateful services. The Gateway Lab records 17 actual HTTP/MCP requests through archived gateway source, using fictional local authentication, API and music services. It verifies allowed forwarding, denied actions and authenticated caller identity. Native profiles curate the catalog; execution permissions remain a separate boundary. This fixture does not test production OAuth or provider credentials.
Source and historical evidence
The bridge and gateway grew alongside the agent clients. Their release history shows catalog caching, canvas connections and enforced runtime permissions developing as separate pieces.
About the demonstrations
Product imagery uses selected material prepared for this portfolio. Recordings show the interface in use. Architecture graphics describe system relationships and do not show live service availability.