SPYN3 is an MCP client to every source you connect and an MCP server to your agent. It catalogs each source's tools, shows them to the agent as folders it can open, namespaces them <source>/<tool>, and proxies each call with that source's credentials.
Why folders
Five servers with twenty tools each is a hundred tools, and agents choose worse as the list grows. They pick the wrong tool, or stop picking. A hub that only concatenates lists is worse than no hub. So SPYN3 starts the agent on a few navigation tools, and the list grows only when the agent opens a source it needs.
The tool catalog
Each source's tool list is stored in Postgres and refreshed when the source is connected and on demand. That has two effects. The folder list renders without calling every upstream. And a source that is down keeps its tools listed, marked as unreachable at the last check, instead of vanishing from the agent's view.
MCP sources
Any remote MCP server that speaks Streamable HTTP can be a source. The dashboard's gallery lists 44 well-known ones with the URL and sign-in method already worked out. Most use OAuth: SPYN3 registers itself as a client, runs the authorization-code flow with PKCE, and refreshes tokens as they expire. Servers that only accept a personal token, such as GitHub's, take a pasted token. Any other server can be added by URL.
Non-MCP systems
Systems that don't speak MCP get tools generated from their connector, and every generated tool is read-only by construction:
postgres/list_tables · describe_table · queryEach query runs inside BEGIN READ ONLY. The database refuses writes, including a data-modifying CTE that starts with WITH.<label>/getGET only — there is no method argument to get wrong. Redirects are not followed, and an optional path allowlist narrows what it can reach.google_drive/list_files · read_fileUses Google's narrowest Drive scope, so only files you hand over through Google's picker are visible to the token.Tool prefixes follow the connector's label, so a Postgres connector labelled Warehouse exposes warehouse/query.
Network safety
Every outbound request is checked after DNS resolution: each address must be publicly routable. Pointing a domain at 127.0.0.1 or at a cloud metadata address does not get a request inside SPYN3's network, and redirects are re-checked rather than followed blindly.
Honest errors
An upstream's failure is reported with the source named and the reason intact: a timeout, a 401 or a rate limit. SPYN3 never falls back to stale data and never returns an empty result in place of an error. Calls are timed and bounded, non-idempotent tools are never retried, and a source that keeps failing is circuit-broken so it can't slow down the others.
Response shape
An upstream's result is passed back to the agent. SPYN3's own navigation and status responses are short plain text, written to cost few tokens. Every proxied call is written to the workspace's audit log with its source and latency, but not its content.
Try it on your own systems
Connect two sources and watch the list stay short
The difference shows up with the second and third source. Free covers three.
Start free