We're building SpinMCP as a hosted way to connect AI tools to the apps your team already depends on.
The idea is simple: your AI client should be able to read, write, and act across approved tools without every team rebuilding the same integration plumbing. SpinMCP gives teams one place to authorize apps, expose tools, and route requests through a managed MCP layer.
What is MCP?
Model Context Protocol, or MCP, is a standard interface that lets AI systems use external tools.
If an API is designed for software to call software, MCP is designed for AI clients and agents to discover what a tool can do, understand the inputs it needs, and call it in a predictable way. That makes it a strong fit for everyday workflows like sending messages, updating records, reading documents, searching data, or triggering internal processes.
Hosted MCP servers make this even easier. Instead of asking every user to run local servers, configure credentials, and maintain integrations, a hosted gateway can centralize the setup and make the tools available wherever the team works.
How does it work?
SpinMCP sits between your AI client and the apps you connect.
You authorize the apps you want to use, choose which tools should be available, and point your MCP-compatible client at the SpinMCP endpoint. From there, the client can request the tools it needs and Spinrun handles the connection layer.
I just want to use MCP
If you use an MCP client like Cursor, Claude Desktop, or another compatible environment, the workflow should stay straightforward:
- Create or sign in to your Spinrun account.
- Connect the app credentials your client needs.
- Open the MCP settings in Spinrun.
- Select the app or toolset you want to expose.
- Follow the connection steps for your AI client.
The goal is to keep the setup close to a normal app authorization flow, not a developer infrastructure project.
I just want to keep using Spinrun
MCP also makes Spinrun workflows more flexible.
As more apps expose MCP-compatible tools, agents can use those capabilities inside broader automations. That means fewer one-off integrations, faster access to new tools, and a cleaner path from "this app has an API" to "my agent can safely use it."
What's the catch?
There should not be a complicated catch.
MCP is useful because it reduces integration friction. SpinMCP is built around the same principle: make it easy to connect tools, keep the authorization flow understandable, and let teams experiment without needing to stand up their own hosting layer first.
Why build this?
Teams are moving from simple chatbots to agents that actually do work.
That shift only works if agents can reach the systems where work happens: inboxes, CRMs, spreadsheets, docs, tickets, calendars, databases, and internal services. MCP gives the ecosystem a common language for those connections.
Spinrun already focuses on end-to-end workflow automation, so a managed MCP layer is a natural extension. It lets us bring more tools into agents faster while keeping the user experience simple.
Is it secure?
Security matters more when AI systems can take action.
SpinMCP should use scoped credentials, explicit app authorization, and clear tool boundaries. Teams should know what an agent can access before they run it, and admins should have a path to govern those tools over time.
That is the direction we are building toward: more integrations, fewer manual setup steps, and a safer way to let AI work across the apps your organization already trusts.
