Open-source MCP server · Python · MIT
Point your agent
at itself.
mcp-glimpse is an MCP server that lets any agent — and its human — see its own environment: every connected server, every tool and its declared annotations, the negotiated capabilities, the context window, and the wire. One tool. The whole board.
Snapshots are analyzed in memory and never persisted.
See the rectangle before you connect
The App, live in demo mode
This is the actual MCP App view mcp-glimpse renders inside a host — running here in demo mode with sample data. It's one self-contained HTML file that makes no external requests.
Prefer full screen? Open the demo in a new tab.
60-second quickstart
Connect, then introspect
1
Add the hosted server
Streamable HTTP — add it as a connector in your MCP host.
https://mcp.mcpglimpse.com/mcp2
Or run it locally
Over stdio, for any local MCP host. Same server object.
uvx mcp-glimpse3
Run the tool
Give it a snapshot of everything you can see.
introspect_mcp_context
Call introspect_mcp_context with a full snapshot for the panoramic
view across every server, or with no argument for the server-only slice —
the contrast is the point.
Every MCP primitive, demonstrated live
Capability matrix
mcp-glimpse doesn't just report MCP capabilities — it exercises them, so you can watch each one work. Interactive capabilities need a stateful session; mcp-glimpse runs one.
| Capability | Declared by | In mcp-glimpse | How it's used |
|---|---|---|---|
| Tools | server | Yes — yes | introspect_mcp_context, submit_feedback |
| Prompts | server | Yes — yes | Guided introspection prompts |
| Resources | server | Yes — yes | glimpse:// reference library |
| Elicitation | client | Yes — yes | Confirms feedback before writing |
| Sampling | client | Yes — yes | Narrates your context in prose |
| Roots | client | Yes — yes | Reads advertised workspace roots |
| Logging / progress | server | Yes — yes | Emitted during analysis |
| Completions | server | Yes — yes | Argument completion for prompts |
Answer-shaped explainers
Learn
A small library of genuinely good MCP explainers — each a question with a direct answer, then the depth.
- What is MCP? Tools vs prompts vs resources MCP (the Model Context Protocol) is an open standard that lets an AI agent connect to external servers and use what they expose. A server can expose three core primitives: tools (functions the model calls), prompts (templates a person selects), and resources (readable content the app loads). The difference is who's in control — the model, the user, or the application.
- What can an MCP server see about you? Surprisingly little. An MCP server can see its own tools, prompts, and resources, the protocol version it negotiated, the transport, and per-request arguments — plus whatever the host chose to surface at initialize (like the client's name). It cannot see your other connected servers, their tools, your model's identity, your context window, your working directory, or your active skills. That panoramic view belongs only to you, the agent.
- Tool annotations explained — and why so few tools declare them MCP tool annotations are optional hints on a tool definition — readOnlyHint, destructiveHint, idempotentHint, openWorldHint, and a human title — that tell a host how a tool behaves before it's called, so the host can auto-approve a read but confirm a write. Very few tools in the wild declare any of them, which means a tool that writes durable data can look, on the wire, identical to one that only reads.
- Elicitation, sampling, and roots: MCP's server→client capabilities Most MCP primitives flow from client to server, but three flow the other way. Elicitation lets a server pause a tool call to ask the user for input. Sampling lets a server ask the client's model to generate text. Roots let the client advertise its workspace folders to the server. All three require an interactive, stateful session and are advertised by the client at initialize — a stateless HTTP server cannot use them.
- Stateless vs stateful MCP transports (what each can and cannot do) A stateful MCP transport keeps a session alive across messages, so the server can hold context, push notifications, and do mid-call back-and-forth like elicitation, sampling, and roots. A stateless transport treats every request independently — it's simpler and scales trivially, but it can only report those interactive capabilities, never use them. If you want an interactive MCP server, statefulness is a gate, not an option.
- How big is your context window — and what do 178 tool definitions cost? Your context window is the total number of tokens your model can hold at once — often 200K for a current frontier model. Every connected tool spends part of it before you type a word: each tool's name, description, and input schema are serialized into the model's context. A heavily-connected agent with ~178 tools can burn roughly 30–45K tokens — 15–25% of a 200K window — purely on tool definitions.
Honest by design
What we do and don't keep
The snapshot you introspect is analyzed in memory and never stored. There's no snapshot logging. The only writes that ever happen are the ones you explicitly make — submitting feedback, or choosing to publish an anonymized share card — and each is confirmed before anything is persisted.