What can you do with this server?

This server exposes four MCP tools for inspecting and causally probing open-weight TransformerLens-supported language models (GPT-2, Pythia, Llama, Gemma, Qwen, etc.) by tracing which attention heads and MLP neurons drive a model's predictions. * trace: Run a prompt and get the predicted next token plus the top attention heads ranked by direct logit attribution and top MLP neurons ranked by activation magnitude. * activations: Dump per-layer activation statistics (shape, mean, std, min/max, max-activating position) for residual streams, MLP neurons, and attention patterns. * patch: Zero-ablate a specific component (e.g. layer 9 attn_out) and see how the predicted token and its logit change, testing causal responsibility. * circuit: Automatically rank candidate heads/neurons by attribution and measure each one's causal effect via single-component ablation to sketch a best-effort circuit. * All tools return structured, schema-versioned JSON and translate errors into parseable structured error objects instead of raising. * Read-only and deterministic: the only side effect is caching model weights locally on first use; runs on CPU by default. * Works with any model TransformerLens's HookedTransformer.from_pretrained supports, including GPT-2, Pythia, Llama, Gemma, and Qwen.

How do I use NeuronScope MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NeuronScope MCP Server trace attention heads for gpt2 predicting 'Tokyo'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

NeuronScope MCP Server

by RudrenduPaul

Overview Schema Related Servers Score Discussions

Python

Local

NeuronScope

PyPI License: MIT

Ask a language model "why did you say that" and get back the actual attention heads and neurons responsible, as JSON, from the command line or from an agent over MCP.

NeuronScope tracing a real gpt2 prediction from the command line, showing the top attention heads and MLP neurons responsible for the output

Install

pip install neuronscope-cli

That gets you the neuronscope command. To install from source instead (for development or to track main):

git clone https://github.com/RudrenduPaul/NeuronScope
cd NeuronScope
pip install -e .

NOTE

The first run of any command downloads the requested model from the HuggingFace Hub (gpt2 is about 500MB) and prints two lines to stderr that are expected, not errors: a CPU-fallback notice if you don't have a CUDA GPU, and an unauthenticated-HF-Hub rate-limit notice. Neither one means anything broke.

Related MCP server: chuk-mcp-lazarus

Quickstart

neuronscope trace gpt2 "The capital of France is Paris. The capital of Japan is" --top-k 5

Real output from this exact command (stderr trimmed to the two expected warnings mentioned above):

Prompt: The capital of France is Paris. The capital of Japan is
Predicted next token: ' Tokyo'
Top attention heads (by direct logit
            attribution)
┏━━━━━━━┳━━━━━━┳━━━━━━━━━━━━━━━━━━━┓
┃ Layer ┃ Head ┃ Logit attribution ┃
┡━━━━━━━╇━━━━━━╇━━━━━━━━━━━━━━━━━━━┩
│     9 │    8 │            4.0679 │
│     8 │   11 │            2.9028 │
│    10 │    7 │           -1.4782 │
│     8 │   10 │           -1.3999 │
│    10 │    0 │            1.1424 │
└───────┴──────┴───────────────────┘
Top MLP neurons (by activation
          magnitude)
┏━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━┓
┃ Layer ┃ Neuron ┃ Activation ┃
┡━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━┩
│    10 │     97 │     7.8394 │
│    11 │    611 │     4.6954 │
│    11 │   2997 │     4.6468 │
│    10 │   1793 │     4.5443 │
│     9 │   1460 │     4.4196 │
└───────┴────────┴────────────┘

gpt2 predicts Tokyo correctly, and head L9H8 is the single biggest contributor to that prediction. Add --json to get the machine-readable version of the same result:

neuronscope trace gpt2 "The capital of France is Paris. The capital of Japan is" --top-k 3 --json

{
  "schema_version": 1,
  "operation": "trace",
  "model": {
    "requested_name": "gpt2",
    "resolved_name": "gpt2",
    "backend": "transformer_lens",
    "device": "cpu",
    "n_layers": 12,
    "n_heads": 12,
    "d_model": 768,
    "d_mlp": 3072
  },
  "prompt": "The capital of France is Paris. The capital of Japan is",
  "predicted_token": " Tokyo",
  "predicted_token_id": 11790,
  "top_neurons": [
    { "layer": 10, "neuron_index": 97, "activation": 7.839381217956543 },
    { "layer": 11, "neuron_index": 611, "activation": 4.695372581481934 },
    { "layer": 11, "neuron_index": 2997, "activation": 4.646785736083984 }
  ],
  "top_heads": [
    { "layer": 9, "head_index": 8, "logit_attribution": 4.067923545837402 },
    { "layer": 8, "head_index": 11, "logit_attribution": 2.9028172492980957 },
    { "layer": 10, "head_index": 7, "logit_attribution": -1.4781968593597412 }
  ]
}

What it does

NeuronScope is a CLI and MCP server built on top of TransformerLens. TransformerLens does the actual model loading, hooking, and activation math; NeuronScope adds a stable CLI, a versioned JSON schema, and an MCP server around it, so a script or an agent can ask "which components drove this output" without writing TransformerLens code directly.

trace: runs a prompt through the model and ranks attention heads by direct logit attribution to the predicted token, and MLP neurons by activation magnitude at the final prompt position.
activations: dumps shape, mean, std, min/max, and the max-activating sequence position for every layer's residual stream, MLP neuron activations, and attention pattern.
patch: zero-ablates one component (resid_pre, resid_mid, resid_post, attn_out, mlp_out, or mlp_post) at a given layer and reports how the predicted token and its logit changed.
circuit: a best-effort automated circuit sketch. Ranks candidate heads/neurons by logit attribution, then measures each one's individual causal effect via single-component ablation. This is not full path-patching with clean/corrupted prompt pairs and does not capture interaction effects between components. The --json output says so explicitly in its method field.
Every command supports --json for a schema_version-stamped document instead of a table, and the same four operations are exposed as MCP tools returning the identical shape via .model_dump(), so a CLI call and an MCP tool call produce the same document for the same input.
Model support is whatever transformer_lens.HookedTransformer.from_pretrained supports. Installing neuronscope-cli today pulls TransformerLens 3.6.0, which supports 249 pretrained checkpoints and aliases (OFFICIAL_MODEL_NAMES), covering GPT-2, Pythia, Llama, Gemma, Qwen, and more. Small models like gpt2 run comfortably on CPU.

NeuronScope does not replace TransformerLens, nnsight, SAELens, Anthropic's circuit-tracer, or Neuronpedia. It wraps TransformerLens for one narrower job: fast, scriptable, agent-callable component tracing on a single prompt. It leaves deeper mechanistic work (SAE training, transcoder-based circuit graphs, hosted feature browsing) to those tools.

CLI reference

Every command takes MODEL (any name HookedTransformer.from_pretrained accepts, for example gpt2 or EleutherAI/pythia-70m) and PROMPT as positional arguments.

Command	Extra flags	What it does
`neuronscope trace MODEL PROMPT`	`--top-k INTEGER` (default 10), `--json`	Ranks top attention heads (logit attribution) and MLP neurons (activation magnitude) for the predicted next token
`neuronscope activations MODEL PROMPT`	`--json`	Dumps per-layer activation summary stats (residual stream, MLP, attention pattern)
`neuronscope patch MODEL PROMPT`	`--layer INTEGER` (required), `--component [resid_pre\|resid_mid\|resid_post\|attn_out\|mlp_out\|mlp_post]` (required), `--json`	Zero-ablates one component and reports the logit/prediction delta
`neuronscope circuit MODEL PROMPT`	`--top-k INTEGER` (default 10), `--json`	Best-effort circuit sketch via ranked single-component ablation
`neuronscope mcp-server`	none	Starts the MCP server over stdio

Global: neuronscope --version, neuronscope <command> --help. Exit codes: 0 success, 1 a runtime error (prompt too long for the model's context window, --layer out of range, etc.), 2 a Click usage error (bad flags), 3 an unsupported model name.

neuronscope circuit ranking candidate heads/neurons by logit attribution and measuring each one's causal effect via single-component ablation

neuronscope patch zero-ablating one component at a given layer and reporting how the predicted token and its logit changed

MCP Server

NeuronScope ships a Model Context Protocol server so an AI agent (Claude, Cursor, or any MCP-compatible client) can trace, inspect, ablate, and sketch circuits directly, without a human invoking the CLI by hand.

Install the extra:

pip install "neuronscope-cli[mcp]"

Add it to your MCP client's config (for Claude Desktop, claude_desktop_config.json):

{
  "mcpServers": {
    "neuronscope": {
      "command": "uvx",
      "args": ["--from", "neuronscope-cli", "neuronscope-mcp"]
    }
  }
}

The server exposes four tools, trace, activations, patch, and circuit, each returning the identical pydantic-model-shaped JSON the CLI's --json flag prints, via .model_dump(), so an agent calling this server and a script calling the CLI get the same document for the same input. A real trace call and its response:

trace(model="gpt2", prompt="The capital of France is Paris. The capital of Japan is", top_k=3)

{
  "schema_version": 1,
  "operation": "trace",
  "predicted_token": " Tokyo",
  "predicted_token_id": 11790,
  "top_neurons": [
    { "layer": 10, "neuron_index": 97, "activation": 7.839381217956543 }
  ],
  "top_heads": [
    { "layer": 9, "head_index": 8, "logit_attribution": 4.067923545837402 }
  ]
}

Errors never raise across the tool boundary: every handler catches its exceptions and returns a structured ErrorResponse dict instead, so a calling agent always gets a parseable result.

WARNING

NeuronScope caps model size (2B parameters by default,NEURONSCOPE_MAX_MODEL_PARAMS) and how many models can load at once (1 by default, NEURONSCOPE_MAX_CONCURRENT_LOADS), but puts no timeout on model loading or forward passes. If you expose this MCP server somewhere an untrusted agent can call it, still put a resource limit around the process (a cgroup, ulimit, or a container memory/CPU cap) as defense in depth rather than relying on these in-process caps alone.

Transport is stdio, so there is nothing to host: the MCP client spawns the server as a local subprocess. Source: neuronscope/mcp_server.py.

Claude Code reads this from a project-level .mcp.json in your repo root, or you can add it with claude mcp add neuronscope -- neuronscope-mcp.
Claude Desktop reads this from its claude_desktop_config.json (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows), under the same "mcpServers" key.
The neuronscope mcp-server CLI subcommand still works as a local, non-uvx alternative that runs the same server over stdio from an existing install.

How it compares

All five of these are real, actively maintained projects doing different jobs. This table compares CLI/JSON-agent-output surface and model coverage, not depth of interpretability research, where TransformerLens, nnsight, SAELens, circuit-tracer, and Neuronpedia are all more mature than NeuronScope. Star counts, release info, and last-push dates below were pulled from each project's GitHub API on 2026-08-03 and will drift over time; check the repos directly for current numbers.

Project	Stars	Last activity	CLI	Agent-callable structured output	Model coverage
TransformerLens	3,750	v3.6.0 released 2026-07-28, pushed 2026-08-03	No (Python library)	No	249 pretrained checkpoints/aliases (its own official list)
nnsight	1,014	v0.7.0 released 2026-05-05, pushed 2026-07-30	No (Python library)	No (returns tensors/Python objects)	Any HuggingFace or PyTorch model generically, no fixed list
circuit-tracer (Anthropic-authored, moved from `safety-research/circuit-tracer`)	2,882	v0.5.2 released 2026-07-18, pushed 2026-07-18	Yes	JSON attribution-graph export; no MCP server	Fixed transcoder allowlist: Gemma-2 (2B), Gemma-3 (270M-27B), Llama-3.2 (1B), Llama-3.1 (8B Instruct), Qwen-3 (0.6B-14B), GPT-OSS (20B)
SAELens	1,492	v6.47.0 released 2026-07-28, pushed 2026-07-28	No (Python library)	No	Any PyTorch model generically; deepest integration is with TransformerLens
Neuronpedia	1,093	continuously deployed, tag v1.0.795	No (hosted web app + REST API)	REST API returns JSON; MCP access exists only via an unofficial third-party wrapper, not the official repo	Models loadable through TransformerLens's model table (GPT-2, Gemma-2, Llama, DeepSeek, etc.)
NeuronScope (this project)	1	this commit	Yes	Yes: `--json` on every command, plus a native MCP server returning the same schema	Whatever TransformerLens's `HookedTransformer.from_pretrained` supports: 249 checkpoints/aliases

The honest differentiation is narrow: NeuronScope is the only one of these with a CLI, a native MCP server, and a versioned JSON schema together in one package, and it's model-agnostic across whatever TransformerLens supports rather than pinned to a fixed transcoder allowlist like circuit-tracer. It is not more capable, more mature, or more widely used than any of these projects.

What is NeuronScope and why does it exist

TransformerLens gives you a Python API for loading a model and running hooked forward passes. That's the right interface for a research notebook. It's the wrong interface for a script that needs a subprocess call and a JSON document back, or for an agent that needs a tool it can call over MCP. NeuronScope exists to be that second interface: the same underlying computation, wrapped so a CLI invocation or an MCP tool call gets back a schema-versioned document instead of a Python object graph.

FAQ

Is this a replacement for TransformerLens, nnsight, SAELens, circuit-tracer, or Neuronpedia? No. NeuronScope is built directly on TransformerLens and does not do anything TransformerLens itself can't already do at a lower level. It doesn't train SAEs (SAELens), do full path-patching circuit discovery with transcoders (circuit-tracer), give you a Python-native tracing context manager for arbitrary PyTorch models (nnsight), or host a browsable feature database (Neuronpedia). It's a CLI and MCP wrapper around one slice of TransformerLens's functionality.

What models are supported? Anything transformer_lens.HookedTransformer.from_pretrained supports, which today is 249 checkpoints and aliases spanning GPT-2, Pythia, Llama, Gemma, Qwen, and others. Run python -c "from transformer_lens.loading_from_pretrained import OFFICIAL_MODEL_NAMES; print(len(OFFICIAL_MODEL_NAMES))" in your own environment to get the exact count for your installed version, since TransformerLens adds models over time.

Does it need a GPU? No. Small models like gpt2 run fine on CPU; that's what the test suite and the quickstart above run on. Larger models will be slow on CPU. NeuronScope does not auto-select Apple Silicon's MPS backend even when available, because PyTorch's MPS backend can silently produce incorrect values for some ops that this project's activation-patching math depends on being exact. Pass device="mps" explicitly in your own code if you want it anyway.

Is it safe to expose the MCP server to an untrusted agent? Only with resource limits in place. See Known limitations below.

How is NeuronScope different from circuit-tracer, the other CLI tool in this list? circuit-tracer does deeper circuit analysis (full attribution graphs from trained transcoders) but only for a fixed allowlist of models: Gemma-2, Gemma-3, Llama-3.1/3.2, Qwen-3, and GPT-OSS. NeuronScope trades that depth for breadth: it works with any of TransformerLens's 249 supported checkpoints with no transcoder training step, and ships an MCP server so an agent can call it directly. The cost is that NeuronScope does single-component logit attribution and zero-ablation, not transcoder-based path patching.

Does the installed version always match what's on PyPI? Run neuronscope --version after installing to check. pip install neuronscope-cli pulls whatever release PyPI has published most recently; the code on this repo's main branch can be ahead of that between releases. Installing from source (pip install -e .) always tracks main exactly, including whatever hasn't been released yet.

What license is NeuronScope under, and can I use it commercially? MIT. You can use, modify, and redistribute it in commercial and closed-source projects, with attribution and the license notice kept intact. The dependencies it pulls in (TransformerLens, PyTorch, the mcp package) carry their own licenses; check those separately if you're redistributing a bundled product rather than just calling neuronscope-cli as a dependency.

Known limitations

circuit is an approximation. It ranks components by logit attribution and measures each one's individual causal effect via single-component zero-ablation on one prompt. It does not do full path-patching with clean/corrupted prompt pairs, and it will not catch interaction effects between components. The --json output states this in its method field so a caller doesn't have to trust prose to know the caveat.
No timeout on model loading or forward passes. Once a request passes the resource caps below, NeuronScope runs the load and the forward pass to completion with no built-in wall-clock limit. If you run the MCP server somewhere an untrusted agent can call it, put a resource limit around the process (a cgroup, ulimit, or a container memory/CPU cap) as defense in depth.
Model size and load concurrency are capped, but only in-process. neuronscope/core/limits.py rejects a model over NEURONSCOPE_MAX_MODEL_PARAMS (2B parameters by default) before any weights are downloaded, and rejects a load once NEURONSCOPE_MAX_CONCURRENT_LOADS (1 by default) other loads are already in flight, both with a structured error rather than a hang or a crash. The size check is best-effort: if a model's parameter count can't be determined (for example, fully offline with nothing cached yet), it fails open rather than blocking a legitimate request, so it's not a hard guarantee on its own -- pair it with a process-level resource limit for untrusted deployments.
HookedTransformer.from_pretrained is deprecated upstream. TransformerLens 3.6.0 emits a DeprecationWarning pointing at TransformerBridge.boot_transformers as the replacement. It still works today, and every command shown in this README ran on it, but NeuronScope's backend hasn't migrated yet. Tracked as an open item; migrating would be a change inside neuronscope/backends/transformer_lens.py, not a change to any CLI command or MCP tool signature.

Contributing

Issues and pull requests are welcome. See CONTRIBUTING.md for dev setup, where the code lives, and what a PR needs before it merges. Quick version:

pip install -e ".[dev,mcp]"
pytest -v

CI runs the same suite on Python 3.10, 3.11, and 3.12 on every push and pull request against main. The suite covers 87% of neuronscope/ (pytest --cov=neuronscope), with the MCP server's less-exercised paths (specific error branches) the main gap.

License

MIT. See LICENSE.

Available Tools

4 tools

activationsA

Dump raw per-layer activation summary statistics (shape, mean, std, min/max, and the max-activating sequence position) for one prompt run through an open-weight TransformerLens-supported model, covering every layer's residual stream, MLP neuron activations, and attention pattern. Call this when trace's top-k ranking isn't enough detail and you need the raw scale/shape of a specific hook point before deciding what to inspect further or patch with the patch tool. Same model constraint as trace: only models HookedTransformer.from_pretrained supports. Read-only and deterministic for a given model and prompt; the only side effect is HuggingFace Hub caching the model weights locally on first use of a given model name, which needs network access that one time. Runs on CPU by default. Output size scales with model depth since it returns stats for every layer, not a top-k subset, so it can be verbose for large models. On failure (unsupported model name, prompt too long for the context window) it returns a structured error object rather than raising. Parameters: model (str), any name HookedTransformer.from_pretrained accepts, e.g. 'gpt2'; prompt (str), the input text. Example call: model='gpt2', prompt='The capital of France is Paris. The capital of Japan is'. Returns JSON with schema_version, operation, model, prompt, n_tokens, and activations (list of {hook_name, layer, shape, mean, std, max_value, max_position, min_value}, one entry per hook point).

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes
`prompt`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but description discloses read-only and deterministic behavior, the only side effect (HuggingFace Hub caching on first use), CPU default, output size scaling with model depth, and structured error handling on failure. This fully covers operational behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence adds value. It is front-loaded with purpose, then flows through usage guidance, constraints, side effects, failure mode, parameters, example, and return structure. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and minimal schema, the description is highly complete. It explains the output schema in detail (schema_version, operation, model, prompt, n_tokens, activations list), covers failure behavior, scalability, and side effects, leaving no significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description compensates fully by defining both parameters: 'model (str), any name HookedTransformer.from_pretrained accepts, e.g. gpt2' and 'prompt (str), the input text.' It also gives an explicit example call, making parameter meaning unambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opening phrase 'Dump raw per-layer activation summary statistics' clearly states the action and target, listing specific statistics and components (residual stream, MLP, attention). It distinguishes itself from sibling trace by explicitly stating it is used when 'trace's top-k ranking isn't enough detail'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs when to call: 'Call this when trace's top-k ranking isn't enough detail and you need the raw scale/shape of a specific hook point before deciding what to inspect further or patch with the patch tool.' Also names alternatives (trace, patch) and notes the same model constraint as trace.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

circuitA

Sketch a best-effort automated circuit for one prompt on an open-weight TransformerLens model: ranks candidate attention heads and MLP neurons by direct logit attribution, then measures each candidate's individual causal effect via single-component zero-ablation, so the result reflects components that actually move the prediction, not just ones correlated with it. Call this when trace's correlational ranking isn't enough and you want a causal pass across multiple candidates without manually calling patch on each one. This is NOT full path-patching with clean/corrupted prompt pairs and does not capture interaction effects between components; the response's own method field restates this caveat so a caller doesn't have to trust prose alone. For rigorous transcoder-based circuit discovery on a fixed set of supported models, use a dedicated tool such as Anthropic's circuit-tracer instead. Read-only, with the same model-weight caching, network-on-first-use, and CPU-by-default behavior as trace; more expensive than trace since it runs one extra forward pass per candidate component being ablated. Deterministic for a given model, prompt, and top_k. On failure it returns a structured error object rather than raising. Parameters: model (str); prompt (str); top_k (int, default 10), how many top-attributed components to test via ablation. Example call: model='gpt2', prompt='The capital of France is Paris. The capital of Japan is', top_k=5. Returns JSON with schema_version, operation, model, prompt, predicted_token, predicted_token_id, components (list of {layer, component_type: 'head' or 'neuron', index, logit_drop_on_ablation}), and method (a string explaining the approximation).

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes
`top_k`	No
`prompt`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and does so excellently: it discloses read-only nature, caching/network/CPU behavior, higher cost than trace, determinism, failure behavior (structured error object), and the methodological limitation that it does not capture interaction effects. This goes far beyond simple mutation/read hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place: purpose, usage, exclusions, behavioral traits, parameter details, example, and return schema. It is front-loaded with the core mechanism, uses clear paragraph separation, and contains no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and presence of an output schema, the description is complete: it covers what the tool does, when to use it, alternatives, limitations, operational behavior, parameter semantics, and the return JSON structure. The output schema is present but the description still enriches it by explaining each field's meaning.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explicitly enumerates all three parameters with types and semantics: model (str), prompt (str), and top_k (int, default 10) explaining 'how many top-attributed components to test via ablation.' The example call further clarifies expected usage, fully compensating for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb+resource+method: 'ranks candidate attention heads and MLP neurons by direct logit attribution, then measures each candidate's individual causal effect via single-component zero-ablation.' It also distinguishes from siblings by explicitly referencing trace's correlational ranking and patch, making the tool's unique purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is given: 'Call this when trace's correlational ranking isn't enough and you want a causal pass across multiple candidates without manually calling patch on each one.' It also states when NOT to use it ('This is NOT full path-patching...') and points to an alternative ('use a dedicated tool such as Anthropic's circuit-tracer instead').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

patchA

Zero-ablate one component (a single transformer block's layer plus a component type such as an attention output or MLP output) in an open-weight TransformerLens model's forward pass, and report how the predicted token and its logit changed relative to the unablated baseline. This is a minimal causal intervention: use it to test whether a component trace or circuit flagged as correlated with a prediction is actually causally responsible for it. Call it after trace or circuit has surfaced a candidate layer/component; it does not search for candidates itself. Read-only in the sense that it writes no files and the ablation only affects that single in-memory forward pass, nothing persists across calls; the same HuggingFace model-weight caching and CPU-by-default notes as trace apply. Deterministic for a given model, prompt, layer, and component. On failure it returns a structured error object instead of raising: an out-of-range layer raises LayerOutOfRangeError, an unsupported model name raises UnsupportedModelError, and a prompt exceeding the context window raises PromptTooLongError, all surfaced the same way. Parameters: model (str); prompt (str); layer (int), the zero-indexed transformer block to patch; component (str), one of resid_pre, resid_mid, resid_post, attn_out, mlp_out, mlp_post. Example call: model='gpt2', prompt='The capital of France is Paris. The capital of Japan is', layer=9, component='attn_out'. Returns JSON with schema_version, operation, model, prompt, layer, component, ablation_type ('zero'), baseline_predicted_token, baseline_predicted_token_id, baseline_top_logit, patched_predicted_token, patched_predicted_token_id, patched_top_logit, logit_delta, and prediction_changed (bool).

ParametersJSON Schema

Name	Required	Description	Default
`layer`	Yes
`model`	Yes
`prompt`	Yes
`component`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behavioral traits: read-only in-memory effect, no persistence, determinism, failure modes returning structured errors, and dependency on trace's caching/CPU defaults. It also clarifies what 'read-only' means, which is critical for a tool named 'patch.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, the description is dense and logically organized: purpose, usage context, behavioral guarantees, error handling, parameters, example, and return fields. Given the tool's complexity and lack of annotations, every sentence serves a purpose and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage, safety, error behavior, parameter semantics, and output shape. It also references sibling tools appropriately. Even with an output schema present, the description adds essential context about causal intervention, determinism, and failure handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description defines every parameter: model as str, prompt as str, layer as zero-indexed transformer block, and component with its full enum of allowed values. An example call grounds the semantics concretely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Zero-ablate one component ... and report how the predicted token and its logit changed.' It clearly distinguishes from siblings by stating it does not search for candidates itself, and explicitly frames it as a causal intervention after trace/circuit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: 'use it to test whether a component trace or circuit flagged as correlated ... is actually causally responsible,' and 'Call it after trace or circuit has surfaced a candidate layer/component; it does not search for candidates itself.' This gives clear when-to-use and relationship to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

traceA

Run a forward pass of a small-to-medium open-weight language model (via TransformerLens) on one prompt, and report which attention heads and MLP neurons were most responsible for its predicted next token: heads ranked by direct logit attribution, neurons ranked by activation magnitude at the final prompt position. Call this to answer 'why did the model predict X' for a specific prompt. It only works on models TransformerLens's HookedTransformer.from_pretrained supports (GPT-2, Pythia, Llama, Gemma, Qwen, and similar open-weight checkpoints), not closed-source APIs like OpenAI or Anthropic models. Read-only and deterministic for a given model, prompt, and top_k: it writes nothing except the model's own weights, which HuggingFace Hub downloads to a local cache (~/.cache/huggingface) the first time a given model name is requested (needs network access that one time; later calls for the same model run offline from cache). Runs on CPU by default and can be slow for large models. On failure (an unsupported model name, or a prompt longer than the model's context window) it returns a structured error object instead of raising, so the tool call itself never fails silently. Parameters: model (str) is any name HookedTransformer.from_pretrained accepts, e.g. 'gpt2' or 'EleutherAI/pythia-70m'; prompt (str) is the input text; top_k (int, default 10) caps how many top heads and neurons are returned. Example call: model='gpt2', prompt='The capital of France is Paris. The capital of Japan is', top_k=5. Returns JSON with schema_version, operation, model (resolved name, backend, device, and layer/head/dimension counts), prompt, predicted_token, predicted_token_id, top_neurons (list of {layer, neuron_index, activation}), and top_heads (list of {layer, head_index, logit_attribution}).

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes
`top_k`	No
`prompt`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses read-only and deterministic behavior, the network/cache side effect on first use, CPU default performance, and the structured error return on failure. This is rich behavioral context far beyond the basic facts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but every sentence earns its place: purpose, use case, model support, constraints, failure behavior, and parameter definitions. It front-loads the primary purpose and then methodically covers context, making it efficiently structured for its complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description covers all essential context: output schema elements, failure modes, network behavior, performance caveats, and supported model families. It is complete enough for an agent to invoke correctly and interpret results, especially with the detailed return signature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameter descriptions (0% coverage), so the description must compensate. It explains 'model' with accepted name examples, 'prompt' as input text, and 'top_k' with default and meaning (caps how many top heads and neurons). This adds meaning well beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Run a forward pass... and report which attention heads and MLP neurons were most responsible for its predicted next token.' It clearly answers 'why did the model predict X' for a specific prompt, distinguishing it from sibling tools like activations, patch, and circuit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this to answer why did the model predict X for a specific prompt,' which is clear when-to-use guidance. It also provides when-not-to-use constraints (only TransformerLens-supported open-weight models, not closed-source APIs). However, it does not name alternative sibling tools for other interpretability tasks, so it lacks explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.9/5.0

Disambiguation4/5

Each tool targets a distinct level of analysis: trace gives correlational top-k attribution, activations provides raw per-layer stats, patch tests a single causal intervention, and circuit automates multi-component causal testing. The only real overlap is trace vs. circuit, but their descriptions clearly differentiate correlational vs. causal use cases.

Naming Consistency5/5

All four tool names are single lowercase words (trace, activations, patch, circuit) with no underscores, camelCase, or prefixes. Though they mix verbs and nouns, the naming convention is perfectly uniform and predictable.

Tool Count5/5

With exactly 4 tools, the server is well-scoped for a mechanistic interpretability toolkit. Each tool covers a distinct need: quick inspection, raw data, single-component ablation, and automated circuit discovery, without bloat or excessive specialization.

Completeness5/5

The tool surface covers the full interpretability workflow: ask 'why' (trace), get detailed activations (activations), test a specific hypothesis (patch), and run a broader causal analysis (circuit). No obvious gaps like model listing or arbitrary patching are necessary for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
TokenOracle
com.guffeyholdings
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Finance Monitoring
2

Related MCP Servers

openinterp-mcp
OpenInterpretability
A
license
Not graded
quality
C
maintenance
MCP server for mechanistic interpretability research, enabling agents to drive probe-causality and SAE-feature experiments via 8 typed tools on user's own compute (Colab).
Updated 3 months ago (2026-06-17 12:30 UTC)
Apache 2.0
chuk-mcp-lazarus
AI & Machine Learning Research & Data
chrishayuk
A
license
Not graded
quality
C
maintenance
Mechanistic interpretability MCP server wrapping chuk-lazarus, enabling model loading, activation extraction, probe training, steering, and ablation via MCP tools.
Updated 5 months ago (2026-03-22 11:18 UTC)
21
Apache 2.0
mitmproxy-mcp
API Testing Browser Automation Web Scraping
u33pk
F
license
B
quality
B
maintenance
A lightweight MCP server built on mitmproxy that lets LLMs capture, inspect, replay, and modify HTTP traffic through a set of focused tools.
Updated 5 days ago (2026-08-29 05:48 UTC)
13
6
Kodama MCP
krazke
-
license
Not graded
quality
Not graded
maintenance
AST-aware code exploration MCP server for AI agents, optimized for token efficiency.
Updated 2 months ago (2026-06-19 12:36 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RudrenduPaul/NeuronScope'

If you have feedback or need assistance with the MCP directory API, please join our Discord server