Context Over MCP, Part VI: Context You Can See

A developer released mcp-context-card, an MIT-licensed MCP server that renders a project's agent context — AGENTS.md sections, memory facts and their file locations — as a visible HTML "context card" so developers can inspect what a coding agent reads before it acts. The server ships 10 tools and 134 tests, is published on npm and the official MCP Registry, and works in any MCP host by resolving the project through the host's MCP roots request or a configurable root path.

Part I asked: Invisible AGENTS.md? Here's the fix. Your coding agent works from context: the project's AGENTS.md , the facts it remembered last week, what it thinks this project is. It reads all of that before it writes a line. You don't see any of it. When the agent does something odd, you go digging: open the repo, find the file, scroll, guess which part it took to heart. Context is vital. But context you can't see is context you can't check. Cards are better when they're visible. TL;DR — see what your AI sees. Nothing to configure. Talk to it goose : add the mcp-context-card extension, open your project, and say "Show me my context card." Terminal: in your project, run npx mcp-context-card card . Either way the full card opens in your browser. The rest of this post is the deeper dive. The repo: mcp-context-card https://github.com/Wolfe-Jam/mcp-context-card : one MIT server for a project's context, memory and identity. 10 tools, 134 tests, on npm and the official MCP Registry, tested in goose. This is the easy route. You talk to goose; goose shows you the card. npx -y mcp-context-card Nothing else. No path, no environment variable. Show me my context card. The server's reply leads with what it did, as a plain fact: New file: or Updated: context-card.html in your project, and the path. The model may put that in its own words; in the screenshot below it says the card was "saved to the project and opened in your browser." Then comes the card as text: the project's name and description, its AGENTS.md sections, the first sentence of each memory fact word for word, and where each one lives. At the same moment the full card opens in your browser. How did it know which project? The server asks the host which folder you're working in, through the standard MCP roots request, and reads that folder. In goose, that's the folder chip. Switch it, and the next card follows. The file it saved is yours to keep. It's a snapshot of what your agent reads, next to the code it describes. No AI, no host. In your project folder: npx mcp-context-card card It writes context-card.html and opens it in your browser. Add --expanded to open every section, for a screenshot or a review with someone else. One page, four parts: AGENTS.md , every section, collapsed so the card scans in one screen. Open any section, or all of them. That's the same material your agent reads. Seen as a page, it does three things the files alone don't: A thirty-second review before a big task: Whatever's wrong on the card is wrong in what the agent reads. Fix the file, ask again, and the card follows. It's generated from your files every time, so it can't drift from them. Try it on a project with no AGENTS.md and the card doesn't stop at "nothing here". Each empty section says what to do next: author agents md tool builds one from the repo's real build and test commands, with nothing invented. Outside a chat, npx agents-md-facts writes the same facts. So the first card shows you the gap and the next step in the same place. The same server works in any MCP host. For hosts that take a JSON entry Claude Desktop, Cursor, and others : { "mcpServers": { "context-card": { "command": "npx", "args": "-y", "mcp-context-card" } } } In Claude Code, from your project folder: claude mcp add context-card -- npx -y mcp-context-card The server finds your project the same way everywhere: the host's MCP roots first, then the folder it was started in, if that has an AGENTS.md . Ask "Which project are you reading?" and it tells you the path and how it found it. To pin one project regardless, set MCP CONTEXT CARD ROOT to its path. What you see depends on the host: Hosts that support MCP Apps the MCP extension for interactive UI show the full card inline, in the chat. When the host says so as it connects, the model gets a one-line summary instead of a page of HTML. That's the MCP Apps reference host drawing the card. It renders apps but doesn't announce that when it connects, so its Tool Result panel still shows the full HTML: the server can only shorten what it knows the host will draw. Every other host gets the text card in the chat, as in the goose example above, and the full card in the browser. The reply also carries a link to the file, and its address in a code block you can copy, for hosts that won't open a local file link. Before this, asking for the card put about 16,500 characters of raw HTML into the chat. Now the reply is about 1,700, and it's something you can read. Ask for the full detail if you want every memory fact in full; the saved page always has everything. A card you can see changes how you work with memory. Remember that the API tests need DATABASE URL set. remember and forget are marked as tools that change your project, so a host that respects that asks you first. In goose, that's the approval setting: in a mode that asks before tools that change files, you'll see the request and approve it. Then ask for the card again, and there's the fact, on the page. When a fact goes stale, you'll notice it on the card before the agent acts on it. Ask it to forget or correct it. Memory is a plain file in your repo, so it goes through code review like everything else. That's the loop: the agent reads context, you see the same context, and either of you can fix it. If you run your own MCP server, the pattern is small, and it needs nothing beyond the standard SDK. file:// root, and listen for the roots-changed notification. No config for the user to get wrong. ui:// resource with the MIME type text/html;profile=mcp-app , serving the card as one self-contained HTML page: inline CSS, no external requests. meta.ui.resourceUri pointing at that resource. Hosts that support MCP Apps fetch it and draw it. The code is MIT: mcp-context-card https://github.com/Wolfe-Jam/mcp-context-card . To build an MCP App of your own and try it in goose, the goose docs walk through it: Building MCP Apps for goose https://goose-docs.ai/docs/tutorials/building-mcp-apps . npx -y mcp-context-card , open a project, and ask npx mcp-context-card card . Its sections match your file's headings. Change a line in Checked 27–30 September 2026: mcp-context-card 1.3.0, installed from npm, in goose Desktop 1.52.0 and in the MCP Apps reference host. Context was always there. Now you can see it, and so can everyone reviewing the work with you. Thanks for reading, and to everyone who's followed Context Over MCP since Part I. Tried it? Tell me in the comments what your card showed you, and what it got wrong. That's what shapes the next version. No time right now? ★ bookmark the repo https://github.com/Wolfe-Jam/mcp-context-card and come back before your next big task. One command, and you'll see what your agent sees. The series, Context Over MCP: