Narrative context for AI agents.

One call

An agent asks about a topic and gets the narratives back as structured frames, not a sentiment score. Each frame names who is involved, where and when, what the tension is, and what response the narrative points toward; beside it sit how much attention the narrative commands, how much evidence carries it, and how many outlets that evidence spans (counted over the evidence still retained, so after a purge it can be narrower than the lifetime evidence count). One result, with illustrative values:

narrative_context(topic="AI safety regulation", limit=3, api_key="<your key>")

{
  "topic": "AI safety regulation",
  "count": 1,
  "narratives": [
    {
      "id": "a3f8b2c1",
      "label": "Industry self-regulation push",
      "story": "Industry groups urged regulators to adopt voluntary standards before legislating",
      "frame": {
        "who": "Tech industry leaders",
        "where": "Silicon Valley",
        "when": "Post-AGI announcement era",
        "tension": "AI safety regulation is too slow",
        "response": "Industry self-governance via standards bodies"
      },
      "relevance": 0.91,
      "attention_mass": 4.28,
      "evidence_count": 47,
      "distinct_sources": 19,
      "source_diversity": 0.40,
      "status": "active"
    }
  ]
}

How it runs

• Standard MCP, stdio transport. Your MCP client spawns the server as a subprocess: Claude Desktop, Cursor, or your own agent through the MCP SDK. There is no WolfTone-specific client.
• It runs beside your data. The server is a process next to the PostgreSQL database that holds the narrative state; the client that spawns it supplies the connection. Beside the SaaS default, the engine's Helm chart ships two restricted postures for the rest of the stack: sovereign, with in-region models and database and egress allow-listed, and air-gapped, with local models in the cluster and zero egress. The chart carries the MCP image too, off by default, because an in-cluster MCP server needs a stdio-to-HTTP gateway that you supply.
• Calls are audited. With authentication on, which the beta runs with, each call carries an API key per caller and a rate limit per key, and each call that reaches the engine writes an audit entry chaining a caller_id through agent-to-agent calls. A call rejected on its arguments returns before the entry; without authentication, calls log as anonymous.

A client configuration, once a checkout and its database are in place. The client starts the server with only the environment you give it here, so the database connection goes in env, beside any key your configured model provider reads. WOLFTONE_ENV names the deployment posture: unset, the server refuses any database outside your own machine, so a remote one needs prod (or gov / airgapped for a restricted deployment).

{
  "mcpServers": {
    "wolftone": {
      "command": "uv",
      "args": [
        "run", "--project", "/path/to/wolftone", "--extra", "mcp",
        "python", "-m", "services.mcp.server"
      ],
      "env": {
        "DATABASE_URL": "postgresql://user:password@host:5432/wolftone",
        "WOLFTONE_ENV": "prod"
      }
    }
  }
}

What it does not do yet

• It is not real time. Ingestion runs as a daily batch, so the index a call reaches can be up to about a day behind the wire.
• Text tools take seconds. Any tool that matches free text against the index runs extraction and embedding in the request path; decompose_narrative runs the extraction alone unless you ask for the vector. Fine for checking a draft; not for a bid-time call.
• Nothing pushes. There is no subscription or alert primitive. An agent that wants to watch a narrative polls its trajectory.
• The experimental tools are unvalidated. They are exposed so agents can interoperate with them, and labelled so nobody mistakes them for the proven core.