DEV Community

Cover image for Context Over MCP, Part VI: Context You Can See
wolfejam.dev
wolfejam.dev Subscriber

Posted on

Context Over MCP, Part VI: Context You Can See

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: 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.

The context card, collapsed to one screen, then every section expanded: identity, AGENTS.md, memory and discovery

Try it: the goose way

This is the easy route. You talk to goose; goose shows you the card.

  1. Add the extension. In goose Desktop: Extensions → Add custom extension. Type Standard IO, command:
   npx -y mcp-context-card
Enter fullscreen mode Exit fullscreen mode

Nothing else. No path, no environment variable.

  1. Open your project. Point goose's working directory at the project you want to see: the folder chip at the bottom of the chat.
  2. Ask:

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.

goose showing the card as text, with the full card opened in the<br>
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.

Try it: the terminal way

No AI, no host. In your project folder:

npx mcp-context-card card
Enter fullscreen mode Exit fullscreen mode

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.

What the card shows, and why it helps

One page, four parts:

  • Identity — what this project says it is: name, version, status, license, one line of description.
  • Context — your AGENTS.md, every section, collapsed so the card scans in one screen. Open any section, or all of them.
  • Memory — every fact the agent has been asked to remember, with a mark on the ones that are verified.
  • Discovery — where each of those lives, and in what format, so a machine can find it too.

That's the same material your agent reads. Seen as a page, it does three
things the files alone don't:

  1. It shows intent. The top of the card is the purpose of the project, stated once. If that line is wrong, everything downstream is aimed wrong.
  2. It shows alignment. Reading the card, you see what the agent will see. A stale build command or a fact that stopped being true stands out on a card in a way it never does in a file you haven't opened in a month.
  3. It puts you back in the loop. You check the context before the agent acts on it, not after, without digging through the repo.

A thirty-second review before a big task:

  • Is the one-line purpose still true?
  • Are the build and test commands the ones you actually use?
  • Is anything in memory out of date?

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.

An empty project is a starting point

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:

  • Context: No AGENTS.md yet. Ask your agent to draft one. The server's 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.
  • Memory: No facts yet. Ask your agent to remember something, and it lands here.

So the first card shows you the gap and the next step in the same place.

In other hosts

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"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

In Claude Code, from your project folder:

claude mcp add context-card -- npx -y mcp-context-card
Enter fullscreen mode Exit fullscreen mode

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.

The card rendered inline by the MCP Apps reference host

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.

Keep it true, with you in the loop

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
mode: Manual asks before every tool, and Smart asks before any
tool marked as changing your project. 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.

How it works, for builders

If you run your own MCP server, the pattern is small, and it needs nothing
beyond the standard SDK.

  • Ask the host which project. Clients that support roots list the folders the user is working in. Read the first file:// root, and listen for the roots-changed notification. No config for the user to get wrong.
  • Declare a UI resource. A 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.
  • Link the tool to it. The tool that renders the card carries _meta.ui.resourceUri pointing at that resource. Hosts that support MCP Apps fetch it and draw it.
  • Check what the client can do. A client that supports MCP Apps can declare it when it connects. Send those clients a one-line summary; send everyone else what they got before.
  • Don't strand the rest. A second tool saves the card, opens it when the server is local, and replies with the card as text, leading with what it did. Server instructions tell the model to use it instead of pasting HTML.
  • Keep the text honest. Each memory fact in the short view is cut at the end of its first sentence, exactly as stored. When we cut mid-sentence with "…", the model tidied the endings into sentences of its own. Memory is the one thing it shouldn't reword.

The code is MIT: 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.

Check it yourself

  1. Add the extension to goose with just npx -y mcp-context-card, open a project, and ask "Show me my context card." The card is that project's, saved in that project's folder, and it opens in your browser.
  2. Switch goose to a different project and ask again. The card follows.
  3. In a terminal, in any project with an AGENTS.md, run npx mcp-context-card card. Its sections match your file's headings. Change a line in AGENTS.md, run it again, and the card shows the change.
  4. Ask the agent to remember a fact, then ask for the card again. The fact is on it.

(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 and come back before your next big task. One command, and you'll see what your agent sees.


The series, Context Over MCP:

Top comments (0)