Allows querying Weights & Biases experiments, including listing projects, runs, metrics, retrieving run details, and plotting metrics as images.
Click on "Install 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., "@mcp-wandb list runs in my wandb project 'mcp-demo'"
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.
🔬 Query your Weights & Biases experiments directly from LLM agents via Model Context Protocol 📊
mcp-wandb is a small Model Context Protocol server for querying Weights & Biases from MCP-compatible clients. It exposes W&B projects, runs, metrics, run details, and metric plots as FastMCP tools over stdio.
Use it when you want an agent to inspect experiment data without switching to the W&B dashboard or hand-copying run metadata.
git clone https://github.com/tsilva/mcp-wandb.git
cd mcp-wandb
uv sync --locked --no-config --exclude-newer '7 days'
export WANDB_API_KEY=your_api_key
uv run python server.pyConfigure your MCP client to run the repo's server.py file, then restart the client.
{
"mcpServers": {
"wandb": {
"command": "python",
"args": ["/path/to/mcp-wandb/server.py"],
"env": {
"WANDB_API_KEY": "your_api_key"
}
}
}
}Related MCP server: ActivityWatch MCP Server
uv sync --locked --no-config --exclude-newer '7 days' # install the reviewed lockfile
uv run python server.py # run the MCP server over stdio
uv run pytest -q # run offline mocked behavior testsget_wandb_projects(entity) lists projects for a W&B entity.
list_wandb_runs(entity, project_name) lists run names, IDs, and states.
list_project_metrics(entity, project_name) returns metric names found across runs.
plot_run_metric(entity, project_name, run_id, metric_names) returns a PNG metric plot as a FastMCP image.
get_run_details(entity, project_name, run_id) returns overview, config, summary, and system metadata.
Python 3.13 or newer is required.
WANDB_API_KEY must be set before invoking a W&B tool. MCP tool discovery and startup do not contact W&B.
The server uses wandb.Api directly and does not keep a local database.
Tests use mocked W&B responses, send no external requests, and exercise registration against the real MCP SDK.
The MCP SDK is held on its patched 1.x line because MCP 2 removes the FastMCP module used by this server.
Retrieve detailed information about a W&B run, including:
Overview (name, id, state, etc.)
Config (user-defined hyperparameters)
Summary (final logged metrics)
System/environment details
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| run_id | Yes | ||
| project_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Retrieve' clearly indicates a read-only operation, and the bullets disclose what types of data are returned. There are no annotations, so the description carries the burden, but it does not mention edge cases, error conditions, or access requirements.
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 concise, front-loaded with the action and resource, and uses a scannable bullet list. Every sentence adds value without unnecessary filler.
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?
With an output schema present, the description does not need to explain return structure, and the bullet list gives a useful overview. Minor gaps around parameter semantics and usage guidance prevent a perfect score.
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 schema has no parameter descriptions, so the description must compensate. It does not explain entity, project_name, or run_id beyond their self-evident names, and 'entity' in W&B context (username/team) is left ambiguous.
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 specific verb ('Retrieve') and resource ('W&B run'), and the bullet list clarifies the scope of information. It does not explicitly differentiate from list_wandb_runs, but the detail-oriented framing makes the distinction sufficiently clear.
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 purpose implies use when detailed information about a single run is needed rather than a list of runs. However, it does not explicitly state when not to use it or name alternatives, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of projects from Weights & Biases.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It indicates a read-only list operation via 'Get,' but it does not disclose pagination behavior, required entity format, access requirements, or any other operational traits beyond the bare operation.
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 front-loaded sentence with no filler. It communicates the action and resource immediately and earns its place without redundancy.
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 simple one-parameter tool with an output schema, the description is minimal but missing key context about the required entity parameter. An agent could invoke the tool but may not understand what entity values are valid, making the description insufficient for correct usage.
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 0%, so the description should compensate for the undocumented 'entity' parameter. It does not explain what values entity accepts, how it affects the returned projects, or what the required format is, leaving the agent to infer from the parameter name alone.
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 states a clear verb and resource: it retrieves a list of projects from Weights & Biases. It differentiates from sibling tools like list_wandb_runs and list_project_metrics through the noun 'projects', though it does not explicitly call out the distinction.
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 intended use is implied by the phrase 'Get a list of projects,' suggesting it should be used when project-level information is needed. However, it provides no explicit guidance on when to prefer this over alternatives, nor does it exclude any sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all unique metric names logged in a W&B project.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| project_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the result is a set of unique metric names rather than raw metric entries, and the scope is limited to metrics logged in the project. It does not mention pagination or ordering, but for a simple list operation this is adequate.
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?
One sentence with no filler, action and object front-loaded. 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?
For a simple two-parameter list operation with an output schema, the description is mostly complete, but it leaves entity semantics and usage context implicit. An agent familiar with W&B conventions could call it correctly; one without that background may struggle.
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 0%, so the description must compensate. It only hints at project context through 'in a W&B project', which maps to project_name, but it does not explain that entity refers to the W&B entity/team or define the expected format. An agent lacking W&B domain knowledge would have to guess.
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 specific verb ('List') and a specific resource ('all unique metric names logged in a W&B project'). This clearly distinguishes it from sibling tools like get_run_details, get_wandb_projects, list_wandb_runs, and plot_run_metric, which target runs, projects, or plotting rather than metric name enumeration.
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 intended use is implied by the resource description, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives. An agent can infer the tool is for retrieving metric names, but is not told when this is preferable to listing runs or plotting a metric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all runs for a given W&B project.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| project_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'List all runs' but does not mention pagination, return format, whether it includes archived runs, or any authentication requirements. For a listing tool, such omissions leave the agent uncertain about response size and handling.
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, efficient sentence with a clear verb, resource, and scope. It is front-loaded and contains no filler, achieving high conciseness and readability.
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's moderate complexity and the presence of an output schema (though not shown), the description still lacks critical context: no pagination info, no differentiation from siblings, and no mention of what 'all runs' implies (e.g., filtering, ordering). It feels underspecified for an agent that must decide when to use it and what to expect.
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 0%, but the description adds no meaning beyond the parameter names. It references 'given W&B project' but does not clarify that 'entity' is the W&B entity/namespace and 'project_name' is the project identifier, nor does it provide examples or constraints. The agent is left to infer parameter roles from the schema alone.
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 'List all runs for a given W&B project' – a clear verb (list), resource (runs), and scope (W&B project). This clearly distinguishes it from siblings like get_run_details (single run) and get_wandb_projects (list projects), so an agent can confidently select it for bulk listing.
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 given on when to use this tool versus alternatives. It does not mention, for example, that for a single run's details one should use get_run_details, or that to explore available projects one should use get_wandb_projects. The description leaves selection entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plot the requested metrics and return the base-64-encoded PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| run_id | Yes | ||
| metric_names | Yes | ||
| project_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait that the result is returned as a base-64-encoded PNG rather than a file path or rendered image. However, with no annotations provided, it does not mention side effects, permissions, or error behavior; for a plotting tool, the disclosed output behavior is the most important part.
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 with no filler; the action and output format are front-loaded. Every word earns its place given the minimal scope of the tool.
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 output is specified, but for a 4-required-parameter tool with no annotations and no schema descriptions, the definition lacks parameter semantics and usage context. An agent would have to infer the meaning of entity/project/run and which metrics are valid, so this is not complete enough on its own.
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 0% and the description adds no parameter-level explanation. 'Requested metrics' loosely maps to metric_names, but entity, project_name, and run_id are left entirely to inference from their names, which may be ambiguous in the W&B context.
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 the action ('Plot'), the target ('requested metrics'), and the output format ('base-64-encoded PNG'). The verb/resource pair is distinct from the sibling get/list tools, though it does not explicitly name a sibling.
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 given about when to choose this tool over siblings such as list_project_metrics or get_run_details. The intended context is only weakly implied by the tool name and parameters, not stated.
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. Dates show when Glama detected each change.
v0.1.0get_run_detailsget_wandb_projectslist_project_metricslist_wandb_runsplot_run_metricEach tool targets a distinct resource-action pair: projects, runs, run details, metric names, and plot output. There is no meaningful overlap or risk of confusion.
All names are lowercase snake_case and verb-first, but conventions are mixed: 'get' and 'list' are used inconsistently for collection-returning tools, and the 'wandb' prefix appears on only some tools. Still readable and predictable enough for an agent.
Five tools form a compact, well-scoped set for reading and visualizing W&B data. Each tool serves a clear purpose without redundancy.
Covers project discovery, run listing, run details, metric discovery, and plotting. However, raw metric history is only accessible through an image plot, and there is no run comparison or filtering, which are common W&B workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Artifact store for AI agents — read, write, and search files by path; share by rendered URL.
Query your Betterlytics web analytics from AI agents: traffic, funnels, journeys, errors, uptime.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tsilva/mcp-wandb'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
