See the architecture your AI built, in one command

You have shipped an app. You can open any file in it. What you probably cannot do, right now, without opening anything, is draw it: every piece, every arrow between pieces, and which of those arrows a stranger can reach.

That's not a knowledge gap, it's a format problem. You built this thing one conversation at a time, and a conversation is a sequence. The system it produced is a shape. Nobody ever converted one into the other, because at no point in the building did you need to.

What a map shows that a file tree doesn't

A file tree answers "what exists." Almost every question that hurts later is a different question:

• What does the most common click actually touch, in order, before the user sees a response?
• If the cache goes down, does the app get slower or go white?
• Which routes reach the database without passing anything that checks who's asking?
• What is talking straight to Postgres from the browser?

None of those live in a file. They live between files, which is why grep doesn't find them and why reading your own code carefully for an hour can leave you exactly as unsure as when you started. Drawn as boxes and arrows, three of the four are visible in about five seconds, because a line going somewhere it shouldn't looks wrong the way a crooked picture frame looks wrong.

The one command

Arketo is a remote MCP server, which is a technical way of saying: it's a URL your assistant can use as a tool. In Claude Code, connecting is one line:

claude mcp add --transport http arketo "<your-mcp-url>" --header "Authorization: Bearer <your-key>"

Your URL comes with your account. In Cursor, Windsurf, VS Code, or anything else that speaks MCP, it's the same URL pasted into that client's MCP settings instead. There is nothing to install, no agent running in the background, no build step, and nothing to add to your repo.

The loop

Then you stop talking to us and go back to talking to your assistant, which is the point.

You say "map the architecture of this app." It reads the code the way it always could, and now it can also draw: components appear on a canvas, connections route themselves, and the whole thing renders live in a browser tab while your assistant is still working. You watch your app get built a second time, in a form you can actually look at.

Then "find the risks." Findings land on the exact component or edge they belong to, sorted by severity, so "this endpoint has no rate limit" is attached to the endpoint rather than sitting in a list underneath the picture.

Then "write it up," and you get a Markdown report with the findings and a phased plan, which you can paste into a ticket, drop in the repo, or hand to whoever asks you next week whether the app is ready.

What it does not do

This is the part worth being clear about, because the honest version is also the reassuring one.

Arketo never reads your repository. It has no access to your machine, your git remote, or your files, and no way to get any. Your assistant reads the code, on your machine, as it already does all day, and then describes the system to Arketo through a handful of drawing tools. What we store is the picture, not the thing it's a picture of.

The direct consequence is that a map is exactly as good as the assistant that drew it. If your assistant misreads something, the canvas will show the misreading, in high resolution, which is genuinely useful: a wrong box is easier to spot than a wrong assumption. But it's a mirror, not an oracle. It doesn't run your app, watch real traffic, or scan your dependencies. It shows you the system your assistant believes it built, and lets you check that against the one you meant to build.

That gap, between the app you think you shipped and the one that's actually running, is where most of the trouble in prompt-built software lives. It costs one command to look.

The demo runs without an account, and /examples has finished maps if you'd rather see the output before connecting anything.