Proporciona una pasarela local para monitorear, verificar y bloquear cambios no autorizados en las herramientas de los servidores Model Context Protocol.
También conocido como gawk-dev/mcpgawk
- Stars
- 1
- Herramientas
- —
- Descargas, 30 días
- 4015
- Última versión
- 0.1.87
- Último commit
- 10 nov 2026
- Licencia
- Apache-2.0
¿Qué es mcpgawk MCP?
mcpgawk es un MCP server. Proporciona una pasarela local para monitorear, verificar y bloquear cambios no autorizados en las herramientas de los servidores Model Context Protocol.
Resumen generado a partir del README del proyecto
Acerca del MCP server de mcpgawk
mcpgawk funciona como una pasarela de seguridad local para desarrolladores que utilizan servidores Model Context Protocol. Aborda el riesgo de que los servidores cambien sus definiciones de herramientas después de la aprobación inicial, un escenario en el que un agente podría ejecutar funciones nuevas y no autorizadas sin saberlo. El software se ejecuta completamente en tu máquina y no sube ningún dato, garantizando que tu inventario y tus decisiones permanezcan privados.
Los usuarios pueden interactuar con el sistema a través de una interfaz de línea de comandos o mediante extensiones dedicadas para VS Code y Cursor. El conjunto de herramientas incluye comandos como mcpgawk guard para instalar hooks de pre-ejecución, mcpgawk verify para probar herramientas en un sandbox y mcpgawk changes para ver las diferencias en las superficies de las herramientas a lo largo del tiempo. Soporta varios transportes, incluyendo stdio, SSE y HTTP. Para equipos que requieren una supervisión más amplia, la plataforma mcpgawk ofrece funciones empresariales como mcpgawk enforce y mcpgawk monitor mediante un modelo de suscripción.
Qué puedes hacer con él
- 1Auditar el comportamiento del servidor de forma aisladaPuedes ejecutar servidores en un sandbox para detectar actividades maliciosas como la exfiltración de datos o SSRF antes de confiar en ellos.
- 2Monitorear los costos de la ventana de contextoLos desarrolladores pueden identificar qué herramientas están consumiendo más tokens para gestionar el rendimiento y la eficiencia del agente.
- 3Detectar actualizaciones silenciosas de herramientasUtiliza la función de seguimiento para identificar cuándo un servidor ha reescrito sus descripciones de herramientas o sus esquemas de entrada.
Escrito a partir del README del proyecto. Cada caso de uso se verifica con una cita del mismo.
Cómo instalar mcpgawk MCP
Formatos verificados el 10 nov 2026Instalar mcpgawk MCP en Claude Code
$ claude mcp add mcpgawk -- uvx mcpgawkInstalar mcpgawk MCP en Cursor
~/.cursor/mcp.json
{
"mcpServers": {
"mcpgawk": {
"command": "uvx",
"args": [
"mcpgawk"
]
}
}
}Instalar mcpgawk MCP en VS Code
.vscode/mcp.json
{
"servers": {
"mcpgawk": {
"type": "stdio",
"command": "uvx",
"args": [
"mcpgawk"
]
}
}
}Instalar mcpgawk MCP en Claude Desktop
claude_desktop_config.json
{
"mcpServers": {
"mcpgawk": {
"command": "uvx",
"args": [
"mcpgawk"
]
}
}
}Instalar mcpgawk MCP en Codex
~/.codex/config.toml
[mcp_servers.mcpgawk] command = "uvx" args = ["mcpgawk"]
Instalar mcpgawk MCP en Gemini CLI
~/.gemini/settings.json
{
"mcpServers": {
"mcpgawk": {
"command": "uvx",
"args": [
"mcpgawk"
]
}
}
}Configuración
GITHUB_PERSONAL_ACCESS_TOKEN
| Nombre | Descripción | Tipo |
|---|---|---|
| GITHUB_PERSONAL_ACCESS_TOKEN | — |
Verificaciones automáticas
Ejecutado 14 nov 2026Informe completo →Pasó nuestras verificaciones automáticas. Esto no es una auditoría de seguridad: lee el código y dale al servidor el acceso más limitado que necesite. Cómo funcionan las verificaciones
- Repositorio de origen vinculado y accesiblegawk-dev/mcpgawk is public and reachablegithub.com/gawk-dev/mcpgawk ↗Aprobado
- El paquete cita este repositorio como fuentemcpgawk names gawk-dev/mcpgawk as sourcepypi.org/project/mcpgawk/ ↗Aprobado
- Procedencia de la compilación (atestación Sigstore)Sigstore attestation for mcpgawkpypi.org/project/mcpgawk/ ↗Aprobado
- Licencia de código abierto (OSI)Apache-2.0spdx.org/licenses/Apache-2.0.html ↗Aprobado
- Commit o lanzamiento en el último añoLast commit or release 2026-11-10github.com/gawk-dev/mcpgawk ↗Aprobado
- OpenSSF ScorecardNo verificado
- El nombre del paquete no es similar a un paquete popularNo popular package one edit away from mcpgawkAprobado
- Sin avisos críticos en el paquete ni en sus dependencias38 resolved dependencies checked; no critical advisoryosv.dev ↗Aprobado
- Sin instrucciones ocultas para el modelo0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersAprobado
- Las herramientas destructivas están etiquetadasNo verificado
- El endpoint remoto responde al handshake MCPNo verificado
README
Ver en GitHubmcpgawk
Your agents call Model Context Protocol servers that can change what their tools do after you approved them, and the agent will call the new one without noticing. mcpgawk reads every server your agents can reach, checks every call against a baseline you approved, and blocks the ones that changed. It runs on your machine and uploads nothing.
The same engine powers mcpgawk Platform: mcpgawk enforce puts one endpoint in front of the
whole fleet with a key per caller, policy on every call and a hash-chained audit log, and
mcpgawk monitor watches the servers you approved around the clock and tells you when one drifts.
This free layer is the seeing and the blocking underneath it. mcpgawk Platform is one subscription
per person for up to 3 machines: start a free 7-day trial at https://mcp.gawk.dev/trial.html?utm_source=github&utm_medium=readme
(no card) or subscribe at https://mcp.gawk.dev/subscribe. Then mcpgawk login <key> on this same
install fetches the paid engine and turns those on — one more command, nothing else to set up.
Why
A server you approved can change what its tools do afterwards. Nothing in MCP tells your agent that happened — it just calls the new tool. That is the rug-pull, and it is the case mcpgawk is built for.
Two things follow from being able to see a server properly. You find out what each one can reach before you trust it, and you find out what it costs: every tool is loaded into your context on every request, used or not.
How it's different
- It blocks, it does not only report. A scanner tells you afterwards.
mcpgawk guardinstalls one pre-execution hook and a tool that appeared after you approved the server does not run. - It runs the server, not just reads it.
mcpgawk verifydrives tools in a sandbox and reports what they actually did — exfiltration, SSRF, poisoning — reproduced before it is reported. - Nothing is uploaded. Cloud scanners send your inventory to a server and gate the verdict there. Every decision here is made on your machine, with no account and nothing to sign in to.
- It says what it did not check. Skipped tools are named as skipped, never counted as clean.
Features
- 🛑 Block a changed tool before it runs —
mcpgawk guard installputs one pre-execution hook in your agent's loop. The decision is local, in about 10ms, with nothing to sign in to. Works on 6 of the 21 supported clients; the rest have no hook point and are named, not glossed over. - 🧪 Run it, don't just read it —
mcpgawk verifydrives tools in a sandbox and reports what they did: exfiltration, SSRF, tool poisoning, secret leaks. The sandbox is a proxy by default, so it needs no Docker; Docker adds full container isolation when you have it. Safe mode drives only provably read-only tools, and every tool it skips is named as skipped. - 🧑⚖️ Approval needs a person —
mcpgawk decideopens a local screen for what changed. The buttons live on the tokened link printed in your terminal, so an agent that opened the page cannot approve its own way past a block. - 🖥️ One local panel —
mcpgawk panel: every server, every decision, every piece of evidence. - 📜 The changelog no vendor publishes —
mcpgawk changesshows every change to a server's tool surface between the snapshots you have recorded: tools added or removed, input schemas widened, descriptions and annotations rewritten. It reads your local history, so it works for a server you approved weeks ago — the one thing a fresh scan can never tell you. - 🔌 Any transport — stdio, streamable-HTTP, SSE, and OAuth remotes (via the
mcp-remotebridge). - 💸 Token cost index — exactly what each tool adds to your context at connect, plus the 3 heaviest tools.
- 🧾 Capability facts — write / exfil-capable / declared annotations, straight from the schema, plus a trust-surface summary (% write, % exfil-capable, destructive-declared count) and an annotation-completeness score.
- 📌 Integrity pin + drift — catch a server that silently rewrites its tools (
--track). - 🚩 Bounded signals — injection-shaped descriptions, cross-server shadowing, under-declaring Server Cards — pointers for a human, never verdicts.
- 🔒 Zero egress, by construction — the measurement layers import no network library. Enforced by a test.
Two checks are opt-in and make an explicit exception (see Guarantees):
--supply-chainand--oauth-scopes.
Get it — three ways
CLI (any terminal):
uv tool install --force mcpgawk # or: pipx install --force mcpgawk
mcpgawk # finds every agent config on the machine itself
Run it as an MCP server: mcpgawk mcp (stdio), or uvx mcpgawk mcp.
Editor (VS Code / Cursor): install mcpgawk from the VS Code Marketplace or Open VSX. It scans your workspace mcp.json and shows cost + capability flags inline. The extension drives this engine as a subprocess — it is built and released separately, so its source is not in this repository.
CI (GitHub Action): gate every PR on token budget / drift (Marketplace):
- uses: gawk-dev/mcpgawk@v1
with: { config: mcp.json, max-tokens: 8000, fail-on-flagged: true }
When to run it
- Once, then leave it on —
mcpgawk guard install. After that a tool that appears on a server you already approved does not get called. - Before you add a server — see what it costs and what it can do, before you trust it.
- When your agent feels slow or picks the wrong tool — it's often MCP bloat (too many / too-heavy tools).
- On every PR — the CI gate catches drift and creeping token cost.
- If you publish an MCP server — see what it costs your users and how it reads to a client, and fix it (usually one line per tool). Lean + well-annotated is a differentiator.
Use
mcpgawk # first run: every agent config on this machine
mcpgawk demo # the whole arc in a sandbox — approve, drift, block
mcpgawk guard install # put the baseline in your agent's loop
mcpgawk guard status # is protection actually on?
mcpgawk decide # what changed, and approve it as a human
mcpgawk panel # the local page: servers, decisions, evidence
mcpgawk verify mcp.json # run the servers and watch what they do
mcpgawk changes # what changed on your servers since you approved them
mcpgawk login <key> # licence? one command fetches the paid engine (enforce, monitor)
Scanning on its own, if that is all you want:
mcpgawk scan mcp.json # a whole config
mcpgawk scan --stdio "npx -y @modelcontextprotocol/server-filesystem@2026.8.31 /tmp"
mcpgawk scan --http https://host/mcp --header "Authorization: Bearer $TOKEN"
mcpgawk scan --sse https://host/sse
mcpgawk scan mcp.json --track # record + detect rug-pulls over time
mcpgawk scan mcp.json --json # machine-readable labels
mcpgawk scan mcp.json --verbose # full per-tool table, not just flagged tools
mcpgawk scan mcp.json --supply-chain # opt-in: npm/PyPI deprecation check (network)
mcpgawk scan mcp.json --oauth-scopes # opt-in: decode a supplied Bearer JWT's scope
Keep tokens out of the config file. Under mcpgawk wrap, an env value written as keychain:<service>
(or keychain:<service>@<account>) is read from your macOS Keychain when the server starts and placed
in the server's environment only. The config holds a reference, the agent sees a reference, mcpgawk
stores nothing. A reference that cannot be read refuses to start the server and names the reference,
never a value.
"github": { "command": "mcpgawk", "args": ["wrap", "--", "npx", "-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "keychain:gh-work" } }
What it reports
- Cost index — tokens each tool adds at connect (named tokenizer; a comparable index, not an absolute Claude count), plus the 3 heaviest tools.
- Trust surface — capability facts (write/mutating, exfil-capable, declared annotations) rolled up into % write, % exfil-capable, and a destructive-declared count.
- Annotation completeness — a transparent composite (annotated ÷ total tools declaring read/write intent), not a risk score.
- Coverage — tools, prompts, and resources counted (
--verbosefor the full per-tool table). - Integrity pin — a hash that changes if the server silently rewrites its tools;
--trackturns it into rug-pull detection over time. - Bounded signals — precise, low-false-positive pointers for a human to review, never verdicts: injection-shaped descriptions (tools and prompts), cross-server name shadowing, and public Server Cards that under-declare what the server actually exposes.
- Supply-chain (opt-in,
--supply-chain) — checks the launched package against the public npm/PyPI registry for deprecation/yank status. - OAuth scopes (opt-in,
--oauth-scopes) — locally decodes a supplied Bearer JWT'sscopeclaim.
Guarantees
- No inventory egress. The only network is the protocol client talking to the server you point
it at. The measurement layers import no network library — they cannot egress by construction
(enforced by a test). Public Server Card discovery is fetched with no auth and no redirect-following.
Two flags are the explicit, opt-in exception:
--supply-chainsends the launched package's name (and pinned version, if any) — never your tool inventory — to the public npm registry or PyPI JSON API.--oauth-scopesmakes no network call at all; it locally decodes a Bearer JWT you already supplied. Neither runs unless you pass the flag. - Facts ≠ heuristics. Exact capability facts and the token index never mix with the bounded heuristic signals — separate in code, separate in output.
- Reproducible. One command, identical numbers.
- Tracks the protocol. Built on the official
mcpSDK, which negotiates the protocol version.
Develop
uv run --extra dev --with mcp --with tiktoken --with httpx python -m pytest -q
CI gate — GitHub Action
Scan your MCP servers on every pull request and fail the build if one gets too heavy or trips a signal. It runs entirely in your runner — nothing is uploaded — and posts a per-server cost/flag table to the job summary.
- uses: gawk-dev/mcpgawk@v1
with:
config: mcp.json # or: stdio / http / sse — a single server
max-tokens: 8000 # fail if any server loads more than this at connect
fail-on-flagged: true # fail if any bounded signal fires
Available on the GitHub Marketplace.
Contributing
Issues and PRs welcome. Please read CONTRIBUTING.md first, and see the design boundaries in THREAT-MODEL.md. Security reports go through SECURITY.md (privately, not a public issue).
License
Apache-2.0 — see LICENSE. Part of the nativerse · gawk.dev family. Site and docs: mcp.gawk.dev. The value is in the repo, not a cloud.
Use it from your agent (skill)
Let your coding agent run the checks itself — whenever it adds, upgrades or audits an MCP server:
# Claude Code: install the plugin (the skill, nothing else)
/plugin install mcpgawk --marketplace gawk-dev/mcpgawk
# Any other agent: copy the skill folder into its skills directory
mkdir -p ~/.claude/skills && cp -r plugin/skills/mcpgawk ~/.claude/skills/mcpgawk
The skill teaches the agent to measure a server BEFORE trusting it, audit an MCP-2 upgrade as a baseline diff instead of blind re-trust, and relay every consent prompt to you verbatim.
Preguntas sobre mcpgawk MCP
¿Cómo agrego mcpgawk MCP a Claude Code?
Ejecuta claude mcp add mcpgawk -- uvx mcpgawk en tu terminal. Añade --scope user para que esté disponible en todos los proyectos.
¿Cómo agrego mcpgawk MCP a Cursor?
Abre ~/.cursor/mcp.json y añade el servidor en mcpServers, usando la configuración de Cursor que se muestra en la sección de instalación de arriba.
¿mcpgawk sube mis datos a la nube?
No, es una herramienta local-first que se ejecuta en tu máquina y no sube absolutamente nada.
¿Cómo gestiona mcpgawk los cambios en las herramientas?
Lee cada servidor, compara las llamadas con una base de referencia aprobada y bloquea las herramientas que hayan cambiado.
¿Puedo usarlo para probar vulnerabilidades de seguridad?
Sí, el comando verify ejecuta herramientas en un sandbox para informar sobre exfiltración, SSRF y envenenamiento de herramientas (tool poisoning).
¿Qué pasa si se omite una herramienta durante un escaneo?
Las herramientas omitidas se nombran explícitamente como omitidas en lugar de contarse como seguras.
