What building AI agents with MCP means right now
In the current Pinksheep product surface, MCP is the client connection layer for a configured agent. You do not start by building one public MCP server per stack. You start by building or choosing an agent, then exposing that specific agent over MCP.
That distinction matters because the MCP endpoint exposes the tools and behavior of the agent you configured. It is not a claim that the client has unrestricted direct access to every system in your stack.
Direct answer
Build the agent first. Then use MCP to connect that agent to a compatible client such as Cursor or Claude Desktop.
Why use MCP
MCP gives you a standard client path for using the same configured agent in tools like Cursor or Claude Desktop. Instead of inventing a different setup for each client, you use the agent-level endpoint and API key flow generated in Settings.
| Concern | Without MCP | With MCP |
|---|---|---|
| Client setup | Different custom path per client | One agent-level MCP contract for compatible clients |
| What gets exposed | Often unclear or ad hoc | The specific agent you configured |
| Auth model | Client-specific | Bearer API key from Settings |
| Review model | Depends on the custom path | Protected actions can stay reviewable depending on the agent setup |
How the current MCP flow works
The verified flow is simple:
- Build or choose the agent. The agent defines the work, connected tools, and review behavior.
- Open the MCP setup in Settings. This is where Pinksheep gives you the endpoint, API key path, and live test.
- Add the agent to a compatible client. Cursor and Claude Desktop are the clearest verified client paths today.
- Test with a read-first prompt. Confirm the client is talking to the right agent before you rely on more sensitive actions.
Implementation steps
Build the agent
Describe the work in plain English, review the plan, and connect the tools the agent actually needs.
Open MCP setup in Settings
Use the current MCP setup flow rather than assuming there is a separate public builder surface for every stack.
Copy the agent-level endpoint
The MCP URL is specific to that agent. It is not one generic workspace-wide MCP server URL.
Create an API key
Generate the key in Settings and use it as the Bearer token for the MCP client connection.
Add the endpoint to the client
Configure the MCP connection in Cursor or Claude Desktop using the endpoint and API key.
Run a read-first test
Confirm the agent responds as expected before relying on protected actions or broader operational use.
Control and review
MCP should not widen the claim boundary. The safer posture is to keep the same control model the agent already has:
- Review the plan first. The agent should not be a black box.
- Start with read-first prompts. Make sure the client is wired to the right agent and the right context.
- Keep protected actions reviewable. Consequential actions should stay inside the current safe claim boundary.
- Use the generated API key path. Do not improvise a second auth model when the current Settings flow already exists.
Frequently asked questions
What is the current MCP flow in Pinksheep?
Build or choose the agent you want to use, copy that agent's MCP endpoint from Settings, create an API key, and add both to a compatible MCP client such as Cursor or Claude Desktop.
Can one agent use multiple connected tools?
Yes. The behavior depends on how the agent is configured and which tools it already uses. The MCP endpoint exposes that specific agent, not a generic platform-wide server.
Do I need to write code to use MCP with Pinksheep?
No. The current verified path is a setup flow in Settings plus MCP client configuration. You do not need to write code just to connect a configured agent to Cursor or Claude Desktop.
How do approvals work with MCP-connected agents?
Protected actions can pause for review depending on how the agent is configured. The safe rule is to start with read-first prompts and keep consequential actions reviewable until the workflow is proven.