Connect iyedy to Cursor
Add iyedy to Cursor as a remote MCP server and work with your architecture diagrams in Cursor's agent, next to your code. The agent reads your models, runs iyedy's checks and prepares changes. It never edits a model itself; you, or someone who can edit the diagram, apply each change in iyedy.
On this page
Cursor has no way yet to introduce itself to iyedy by its address. You add iyedy to Cursor's mcp.json with iyedy's client ID for Cursor, cursor, and the scopes to ask for. There is no secret: leave CLIENT_SECRET out.
Before you start
- An iyedy account. Sign in once at app.iyedy.com with the identity you will use from Cursor, and finish creating your account. Cursor sees exactly the diagrams this account can read.
- The Cursor desktop app, on a computer with a web browser. The sign-in comes back to Cursor on port 8787 of this computer.
- In an iyedy organisation (Team, Enterprise), access for MCP clients is off until an owner asks support@iyedy.com to turn it on, and Cursor must be on the organisation's list of allowed clients (see In an iyedy organisation). Your personal workspace works right away.
Set up
- Add iyedy to mcp.json
Open
~/.cursor/mcp.json(for every project) or.cursor/mcp.jsonin a project, and add iyedy tomcpServers, exactly as here:{ "mcpServers": { "iyedy": { "url": "https://app.iyedy.com/mcp", "auth": { "CLIENT_ID": "cursor", "scopes": ["cartouche.read", "cartouche.graph", "cartouche.propose", "offline_access"] } } } }Save the file. Keep the four scopes: without them, Cursor asks for scopes that iyedy does not give it, and the sign-in is refused.
- Start the sign-in
Open Customize in Cursor's sidebar, find iyedy among your MCP servers and start its sign-in. Your browser opens iyedy's sign-in page on
auth.iyedy.com. - Sign in to iyedy
Sign in as you do in the app: e-mail and password, Google, or your organisation's single sign-on.
- Approve the access
Check that the page is on
auth.iyedy.comand that it names Cursor, read what Cursor asks for, then select Allow.On auth.iyedy.com · the access page for Cursor The iyedy access page in the browser: the address bar shows auth.iyedy.com, the card says Cursor wants to use your iyedy account, lists four permissions and ends with Deny and Allow.
- The address is auth.iyedy.com. Cursor never sees your password.
- What Cursor will be able to do: read your diagrams, search and analyse impact, preview changes and submit proposals, and stay connected while you are away. Nothing here edits, deletes or shares a diagram. Select Allow only when you are adding iyedy yourself; if this page opens while you are connecting another server, select Deny.
- Allow hands the sign-in back to Cursor, which keeps it for you.
- Ask Cursor
iyedy's tools appear under the server in Customize. Open the agent and try: “List my iyedy diagrams and explain how the claims platform is built.”
You are done when the agent answers with the names of your own diagrams.
Use it
Cursor's agent uses iyedy's tools when your request needs your diagrams; name iyedy or a tool to help it. Try:
- “What depends on the Claims API? Show me the impact across my diagrams.”
- “Run the checks on the Claims Platform diagram and summarise the findings.”
- “Compare the containers view of the Claims Platform with the services in this repository.”
- “Prepare a proposal that adds a Fraud Scoring service called by the Claims API.”
Cloud Agents keep their own sign-in, separate from the desktop app's: sign in from the server's cloud row in Customize if you use them.
What Cursor can do
The agent picks the tools from your request. Reading tools never change anything. The two tools that store something only reach a proposal, never the model.
Read and analyse
Diagrams, views, versions, findings, dependencies across diagrams.
Propose a change
Preview a change, then submit it as a proposal that a person reviews in iyedy.
A proposal from Cursor waits in iyedy, labelled with the app it came from, until someone who can edit the diagram applies or rejects it. A proposal nobody handles is deleted 30 days after it was made.
What Cursor sees, what stays in iyedy
- It acts as you. Cursor reaches the same workspaces, diagrams and roles as your iyedy account, never more. A diagram you cannot open does not exist for it.
- Up to a ceiling. Confidential on personal workspaces, Internal on Team and Enterprise. Restricted diagrams are never sent. Values that look like secrets are replaced before they leave iyedy.
- Nothing changes without a person. The agent can submit a proposal or withdraw its own; you, or someone who can edit the diagram, apply it in iyedy.
- Your data. iyedy does not use your diagrams to train AI models. What Cursor does with what it reads is covered by your Cursor terms and your team's settings.
Full details: Assistants connected through MCP and the Privacy policy.
Disconnect
- In Cursor. Log out of iyedy, or remove it, in Customize; or delete its entry from
mcp.json. Log out of the cloud row too if Cloud Agents signed in. - On iyedy's side. There is no screen for this yet: write to support@iyedy.com. Support removes Cursor's access, which also ends its renewals; an access already issued stays valid for the rest of its 15 minutes.
See Sign-in, permissions and disconnecting.
In an iyedy organisation
In Team and Enterprise, access for MCP clients stays off until an owner writes to support@iyedy.com. Cursor connects only when the organisation's list of allowed clients names it: without a list, a Team organisation allows Claude and Claude Code only, and an Enterprise organisation none. The owner asks support to add Cursor. Members then connect with their own iyedy account, under the organisation's ceiling and its single sign-on. See Claude and MCP for your organisation.
If it doesn't work
Cursor says the server does not support dynamic client registration
The auth block is missing or misspelt. iyedy never lets a client register itself: copy the block of step 1 again, with CLIENT_ID in capitals, and save.
Cursor reports invalid_scope at once, before any sign-in page
Cursor asked for a scope iyedy does not give it. Keep exactly the four scopes of step 1.
“This organization does not allow Cursor as an MCP client.”
Your iyedy organisation has not added Cursor to its list of allowed clients. An owner asks support to add Cursor. Your personal workspace still works.
More symptoms, and MCP Logs in Cursor's output panel: Coding assistant troubleshooting.
Was this page helpful?Your answer is anonymous and counts only if you accepted measurement.
What went wrong?
Don't write personal data.