Integrate

MCP Server

Low-level, AI-native access to the Signal Graph, for integrating Watt into an agentic system you already run.

The Watt MCP server is low-level access to the Signal Graph, designed for AI traversal, not deterministic, human-style traversal like a REST API or a SQL query. It exposes primitives for moving through the graph, pulling signals in and out of the model's context window, and running data-science functions over signals. An agent reasons with these primitives; you don't call them like fixed endpoints.

The most common mistake is treating the MCP server like an API: pinning your code to specific tool names and input/output shapes. It isn't one. The tools are AI-native and the graph indexes ever-changing raw signals, so the surface evolves. Build an agent that introspects and adapts, not an integration that hardcodes. The introspection section below is the most important part of this page.

When to use it

Most people should not start with the MCP server. It's the lowest-level access primitive and requires advanced signal engineering. We highly recommend proving out repeatable results with the plugin first.

How to connect

The two endpoints share data, but they aren't always the same tools and schemas. We provide a production-grade endpoint and an experimental endpoint. The experimental endpoint updates frequently (often multiple times a week) and is used to test upcoming changes and improvements. New functionality lands in experimental; production lags roughly a couple of weeks behind, receiving updates only once they're battle-tested.

EnvironmentURLUse it for
Productionhttps://api.wattdata.ai/v2/mcpYour live application
Experimentalhttps://api.wattdata.xyz/v2/mcpTesting changes before they hit production

Versioning. The servers are versioned (currently v2). We work hard to lock tool shapes within a major version. Breaking changes ship as a new major version with a 30-day sunset window on the prior production version.

Authentication. The server supports standard OAuth or API key auth. Most direct integrations use an API key; create one for your organization from your account. Pass API keys within the Authorization header:

Authorization: Bearer <YOUR_API_KEY>

What it can do

These are the capability groups the server exposes over the Signal Graph. We describe them at this level, not as a tool-by-tool reference with fixed schemas, on purpose. Tool names and shapes evolve; the capabilities are stable. For the exact, current tools, introspect the server.

  • Traverse the graph. Semantically search the signal catalog from a plain-English idea, look up known signals and their metadata (size, prevalence, skew), and relate entities across the graph.
  • Find entities. Turn a boolean combination of signals into a set of entities, match a file of your own identifiers (email, phone, name + address) to graph entities, and pull their profiles.
  • Analyze signals and entities. Perform data science over collections of entities. Computing lift against the world baseline, scoring, profiling, and grouping by signal are a few of the things you can do.
  • Manipulate data outside the context window. Upload and download files, and use resources to intersect and transform data without routing it through the model's context.

Build on it by introspecting it

This is the part everyone gets wrong, and the part that makes everything else work. MCP tools are self-documenting by design. The best, always-current way to learn what the server exposes is to ask Claude to introspect it. Don't build against this page's capability list; build against what the server reports about itself right now.

Add the server to Claude

Connect the Watt MCP server (or install the plugin, which bundles it).

Ask Claude to introspect it

Run a prompt like the one below. Claude will enumerate every tool the live server exposes, with current inputs, outputs, and resource URIs.

Introspect the Watt MCP server and write a full spec of every tool it
exposes: inputs, outputs, defaults, and resource URIs, grouped by what
each one does, so I can build against it.

Build against what it reported

Use the introspected spec as your source of truth, not a static doc. Re-introspect against experimental to see changes before they reach production.

Tips for building well

  • Decouple your code from our output shapes. One of the benefits of resources is that you don't have to depend on a fixed response format. Best practice for an agentic integration is to have your agent read and transform resources on the fly, and enforce your own output contract downstream, rather than hardcoding against ours. This is the single biggest thing that keeps an integration from breaking when the surface evolves.
  • Use resources to keep your data private. The server uses MCP resources to export data from the graph and to intersect and analyze data you upload without exposing it to the rest of the system. Your uploaded data stays in your workflow context. See Data handling for the full posture.
  • It's for agents, not request/response code. If you find yourself writing imperative calls with fixed payloads, step back; that's the API mental model, and it fights the design. Let an agent reason over the primitives.
  • Rate limits. The default is 600 requests per minute. Need more? Request an increase from your account.

On this page