For most of last year I had two windows open at all times. On the left, an AI agent I was using for real work — drafting, coding, summarising. On the right, Scopeyard, where the actual delivery lived: the board, the deliverables, the client approvals. And I spent an embarrassing amount of my day being a human bridge between the two. Copy a status out of one, paste it into the other. Ask the agent to draft review notes, then go and paste them onto the deliverable myself. Tell a client "you've got three things waiting" by hand, because the agent had no idea Scopeyard existed.
At some point the absurdity of it landed. I was using agents that could reason about my whole business, and then manually retyping their output into the one tool where delivery actually happens. The agent was smart. It was just locked out of the room where the work lived.
So we built the door. This is the story of how we launched the Scopeyard MCP — what it is, the decisions we made, and what it changed.
Before Scopeyard, I spent years running a product studio and then delivering AI automation projects across healthcare, recruitment and operations. If there's one thing that job teaches you, it's that the tools don't win on features. They win on friction removed. So we focussed on:
- Enabling Real Actions
- Ensuring Correct Permissions
- And Zero Setup Friction
Let me walk through the journey.
1. We started from the delivery loop, not the demo
It's easy to ship an "AI integration" that reads a bit of data and looks clever in a screenshot. That wasn't the point. The point was the delivery loop that eats agency time: draft a deliverable, move it across the board, send it for review, chase the approval, report on what's blocking the sprint. That loop is where hours disappear.
So the first decision was that the MCP had to do things, not just answer questions. Your agent can create, update, delete and move deliverables, send work for review, invite teammates and clients, pull a project health report, and — on the client side — approve work through a client_approval action. The test we held ourselves to was one sentence: could a founder say "send the homepage designs for client review and tell me what else is blocking the sprint" and have it just happen? If the answer was no, we weren't done.
2. We used MCP because it stopped being a bet
We didn't want to build a bespoke plugin for Cursor, then another for Claude, then another for ChatGPT, and maintain all three forever. The Model Context Protocol solved that. Write one server, speak to every agent that speaks MCP.
The timing helped. By late 2025 MCP had gone from an Anthropic experiment to genuine infrastructure — in December 2025 it was donated to the newly formed Agentic AI Foundation under the Linux Foundation, with OpenAI, AWS, Google, Microsoft and others backing it. Adoption followed: the protocol crossed roughly 97 million monthly SDK downloads by early 2026. When a standard has that kind of gravity, building on it isn't a gamble any more. It's the obvious move. If it speaks MCP, it now speaks Scopeyard.
3. We chose personal access tokens over OAuth on purpose
This was the decision we argued about most. The "proper enterprise" answer is a full OAuth app-registration flow. We didn't launch with that, and it was deliberate.
Agencies are small, fast and allergic to setup. An OAuth dance — register an app, configure redirect URIs, manage client secrets — is a wall most people bounce off before they ever see value. So for launch we chose personal access tokens. You sign in, go to Account → Personal access tokens, create one, and copy it once. Point your agent at the Scopeyard server URL with an Authorization: Bearer sy_pat_… header, and you're connected in under two minutes. No app registration, no OAuth ceremony.
The trade we made that back: the token is shown exactly once at creation, it's never your password, and you can revoke it instantly from Account settings the moment anything feels off — without locking yourself out of anything else. For a two-minute setup that a non-technical founder can actually complete, that felt like the right balance to ship first.
To be clear, this is a starting point, not the destination. OAuth is firmly on the roadmap, for two reasons. The first is larger teams that want managed, revocable access without passing tokens around by hand. The second is distribution: we want Scopeyard to be a one-click connector inside Claude's directory and the other MCP marketplaces, and those stores are built around OAuth — a user clicks "connect", authorises, and they're in, no copy-pasting a token from Account settings. Personal access tokens got the feature into founders' hands in minutes; OAuth is how we get it onto the shelves where people already go looking for agents' tools.
4. We made access follow your role, not the token's ambition
Here's the part I care about most, because agents acting on your behalf is exactly where things go wrong if you're careless. When an agent can approve deliverables, invite people and touch client-facing projects, "it can do anything you can do" is not a good enough answer. It needs to be "it can do only what you can do."
So a token inherits your Scopeyard role and nothing more. An agent can never overreach your own permissions. This matters enormously on the client side. Clients connect with their own token and see only what the portal already allows them to see — pending approvals, project status, billed work, delivered assets. They can't move board lanes or send work for review. They approve through client_approval, exactly like they would in the portal. Every action an agent takes is your action: fully auditable, under your control, revocable in seconds.
I've watched enough integrations leak permissions to know this isn't a nice-to-have. It's the whole trust model.
5. We refused to pick a favourite agent
Agencies don't all use the same tools, and I didn't want to force a choice. So the MCP is deliberately host-agnostic. Wire up a remote server URL and a Bearer token, and you're in — whether that's Cursor, Claude, ChatGPT, Google's Antigravity, or anything else that supports remote MCP with Bearer auth.
| Agent | Where you configure it |
|---|---|
| Cursor | Settings → Tools & MCP, or edit ~/.cursor/mcp.json (Agent mode) |
| Claude | Claude Code CLI, Claude Desktop, or Claude.ai connectors |
| ChatGPT | Add a remote MCP server as a connector (Developer mode) |
| Antigravity | Configure remote servers in mcp_config.json |
| Anything else | Remote MCP + Bearer auth — it connects |
The point of the table isn't the tools. It's that we didn't want the answer to "does it work with what I use?" to ever be no.
6. We made the server greet you like a person
One small thing I'm quietly proud of. The first time you connect, you don't get a wall of undocumented tools. Ask your agent "what can I do in Scopeyard?" or run the get_started prompt, and the server greets you by name and shows examples tailored to your actual role.
If you're on the agency team, it shows you the delivery loop — see what's on the board, send for review, check project health, invite people, create a deliverable. If you're a client, it shows you the four things you actually care about: what's waiting on your approval, what's already billed, the health of your project, and which assets have been delivered. Same server, different front door depending on who's knocking. Onboarding for an agent should be as thoughtful as onboarding for a human, and this was our version of that.
7. What actually changed
The honest test of any launch is whether your own behaviour changes. Mine did. The two-window bridge is gone. Approvals that used to sit in an inbox for days now happen inside one message — a client can literally say "approve the brand guidelines, the rest can wait" and it's done. And the delivery admin that used to fragment my afternoon now happens in the same conversation where I'm already working.
It also sharpened something we'd believed for a while: the winning move for agencies isn't adding another dashboard humans have to check. It's letting the systems talk to each other so people don't have to. The MCP is that belief made concrete. It's the natural extension of everything Scopeyard is built around — milestone-based delivery, client approvals as a tracked step, unlimited client access — now reachable from whatever agent you already live in. If you run AI automation projects yourself, the AI agencies page shows how the pieces fit, and the full setup lives on the Scopeyard MCP page.
Final thoughts
We didn't launch the Scopeyard MCP to be first, or to put "AI" on the homepage. We launched it because I was tired of being the copy-paste layer between a smart agent and the tool where my delivery actually happens. Removing that friction turned out to be the whole product decision.
Your agent already knows how to work. The only question worth asking is whether you've let it into the room where the work lives.