# Context Over MCP, Part VI: Context You Can See

> Source: <https://dev.to/wolfejam/context-over-mcp-part-vi-context-you-can-see-1daa>
> Published: 2026-10-01 13:09:12+00:00

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