Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Neuronpedia MCP Server Explain feature 5 in GPT-2 Small layer 8"
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.
A Model Context Protocol (MCP) server that provides access to the Neuronpedia API for AI model interpretability and feature analysis.
Explanations: Generate and search explanations for AI model features
Activations: Analyze feature activations on specific text inputs
Steering: Control model generation using specific features
Vectors: Create and manage custom steering vectors
Related MCP server: Jina AI MCP Server
npm install
npm run buildSet your Neuronpedia API key as an environment variable:
export NEURONPEDIA_API_KEY=your_api_key_hereYou can obtain your API key by logging in at neuronpedia.org and visiting your account page.
npm startgenerate_explanation - Generate explanations for model features
search_explanations - Search existing explanations
get_activations - Get feature activations for text
search_top_features - Find top activating features
steer_generation - Steer model generation with features
create_vector - Create custom steering vectors
list_vectors - List all vectors
get_vector - Get specific vector
delete_vector - Delete a vector
Add this to your MCP client configuration:
{
"mcpServers": {
"neuronpedia": {
"command": "node",
"args": ["/path/to/neuronpedia-mcp/dist/index.js"],
"env": {
"NEURONPEDIA_API_KEY": "your_api_key"
}
}
}
}npm run devMIT
Create a custom vector for steering
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Vector name | |
| values | Yes | Vector values | |
| steeringStrength | No | Optional steering strength |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the action, not side effects (e.g., resource creation, persistence), permissions required, or idempotency. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description lacks details about what the tool returns, constraints (e.g., name uniqueness), or how it interacts with other tools like steer_generation. Incomplete for a creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's own parameter descriptions (name, values, steeringStrength). It does not clarify the role of steeringStrength or value format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a custom vector for steering' clearly states the action (create) and the resource (custom vector) and its purpose (steering), which is distinct from sibling tools like list_vectors, get_vector, delete_vector, and steer_generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit context or when-to-use guidance is provided. It is implied that this tool is used when you need to create a custom vector, but there is no mention of alternatives or prerequisites, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a vector by ID
| Name | Required | Description | Default |
|---|---|---|---|
| vectorId | Yes | Vector ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a destructive operation but lacks details on side effects (e.g., irreversibility, permissions needed), which are important for a delete action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately concise but may be too brief for full clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. However, for a deletion tool, additional context on permanence or prerequisites would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional meaning beyond the schema. The parameter 'vectorId' is already described in the schema as 'Vector ID', so no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (delete), the resource (vector), and the identifier method (by ID). It clearly distinguishes from sibling tools like create_vector and list_vectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an explanation for a specific feature in an AI model
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | Layer number | |
| model | Yes | Model name (e.g., gpt2-small) | |
| feature | Yes | Feature number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose whether generation triggers a computation, requires authentication, modifies state, or has side effects. For a generation tool, the agent needs to know if it is a read-only operation and its resource intensity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise, though it could benefit from a brief note on usage context while remaining efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and no output schema or annotations, the description is minimal. It does not explain the nature of the explanation (e.g., text output, confidence scores), error conditions, or any prerequisites. The agent lacks sufficient context to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (coverage 100%), so the description need not add much. It adds no additional meaning beyond the schema. According to guidelines, baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate) and resource (explanation for a specific feature in AI model). However, it does not differentiate from sibling tools like search_explanations, which might retrieve existing explanations. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like search_explanations, get_activations, or search_top_features exist, but the description does not contextualize when generation is appropriate versus searching or retrieving activations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get activation values for a specific feature on given text
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Input text to analyze | |
| layer | Yes | Layer number | |
| model | Yes | Model name | |
| feature | Yes | Feature number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits disclosed beyond the basic action. No annotations provided, so description carries full burden but fails to mention error handling, performance, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with key action. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and 4 required parameters; description does not explain return values or behavior, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. Tool description adds no additional meaning beyond schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'activation values', and specifies the target (specific feature on given text). It differentiates from siblings like generate_explanation by focusing on activation retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like steer_generation or search_top_features. No context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific vector by ID
| Name | Required | Description | Default |
|---|---|---|---|
| vectorId | Yes | Vector ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral details. It only states the basic operation, omitting whether it is read-only, failure behavior (e.g., missing ID), or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the tool has no output schema and the description fails to explain return values or error handling. It is minimally adequate but leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description ('by ID') echoes the schema description ('Vector ID'). The description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific vector by ID' clearly states the verb (Get), resource (vector), and identification method (by ID). It distinguishes from sibling tools like list_vectors (lists all) and create_vector (creates new).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_top_features or get_activations. The description implies usage when a vector ID is known, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all custom vectors
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavior beyond listing. Lacks details on pagination, permissions, or output format, but the operation is straightforward for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. Could be expanded slightly for clarity but is appropriately sized given no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about return format, which is not covered by output schema. With sibling tools that have parameters, the description feels incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds no extra meaning but also has no gaps. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List all custom vectors' with a specific verb and resource, clearly distinguishing from sibling tools like create_vector and get_vector.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as search_explanations or search_top_features. Missing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for explanations across models and layers
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | Optional layer filter | |
| model | No | Optional model filter | |
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only says 'search for explanations'. It does not disclose read-only nature, pagination, rate limits, or what 'explanations' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no waste. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple search tool but lacks details about return format or pagination. No output schema exists, so more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'explanations' with scope 'across models and layers', which distinguishes it from siblings like generate_explanation and search_top_features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., search_top_features for features, get_activations for activations). No explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the top activating features for given text
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Input text to analyze | |
| topK | No | Number of top features to return (default: 10) | |
| layer | Yes | Layer number | |
| model | Yes | Model name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is a single sentence lacking details on side effects, permissions, or data scope. It does not disclose whether the tool is read-only or what 'activating features' entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, with no wasted words. However, it could benefit from slight restructuring to front-load key information like the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, and the complexity of 'activating features', the description is incomplete. It does not explain what the return value is, how to interpret results, or any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find the top activating features for given text' clearly indicates what the tool does: it retrieves activating features for a text input. It uses a specific verb and resource, and although it doesn't explicitly distinguish from siblings like 'get_activations', the term 'activating features' is distinct enough to convey the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool compared to alternatives like 'get_activations' or 'search_explanations', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Steer model generation using a specific feature
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | Layer number | |
| model | Yes | Model name | |
| isChat | No | Whether this is a chat model (default: false) | |
| prompt | Yes | Generation prompt | |
| feature | Yes | Feature number | |
| steeringStrength | Yes | Steering strength (-10 to 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the action ('steer model generation') but fails to mention behavioral traits such as whether the tool is destructive, requires authentication, affects model state, or produces side effects. The term 'steer' is vague without further elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource. It is concise, but could be slightly improved by expanding on the effect of steering. Nonetheless, no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns, the behavior of steering, or any constraints. The description is too minimal for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The tool description adds no additional meaning beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('steer') and identifies the resource ('model generation') and scope ('using a specific feature'). It distinguishes itself from sibling tools like 'generate_explanation' or 'search_explanations' by implying a modification during generation, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to choose 'steer_generation' over 'generate_explanation'). No mention of prerequisites, exclusions, or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_vectordelete_vectorgenerate_explanationget_activationsget_vectorlist_vectorssearch_explanationssearch_top_featuressteer_generationScored across 9 tools
Each tool targets a distinct operation: explanation generation/search, activation retrieval, feature search, steering, and vector management. No two tools have overlapping purposes, ensuring clear disambiguation.
All tool names follow a consistent snake_case verb_noun pattern (e.g., generate_explanation, list_vectors, delete_vector), making the set predictable and easy to navigate.
With 9 tools, the set is well-scoped for a focused domain like neuronpedia. It covers essential operations without being too sparse or overwhelming.
The tool surface provides a complete workflow: explanation generation and search, activation analysis, feature search, steering via vectors, and full CRUD for custom vectors. No obvious gaps.
Run AI models, create deployments, and manage predictions via cloud API
Create, watch, pay for and connect hosted AI agent pods on AgentsPodium. Needs an API key.
Image, video, music and text generation across 100+ models through one endpoint.
Create AI images and videos, manage projects and credits, and use workspace campaign context.
