MCP for agents

# What your agents actually get

The map is served over MCP — the open protocol your agents already speak. Read-only by default: fourteen tools that answer, two that build your map when you allow it, one that asks us for what is missing, eight that act only when you say so, and one that asks before an agent acts in your own systems. While you test the map together, one more lets your agent flag a join it finds wrong and report the counts that settle it. It changes nothing on the map unless a key that may act reports agreeing counts on a review Maplith opened, which confirms that join; otherwise a person decides. Works in Claude Code and as a claude.ai connector over OAuth. [Connect your own agent in three steps](https://maplith.com/docs/own-agent): sign in, connect it, paste one prompt. Every tool is in the [MCP reference](https://maplith.com/docs/mcp).

Maplith does not replace your agent. It gives the agent you already run what it would otherwise rebuild from zero on every task: where things are, what needs doing, what the task touches, and whether it may act. Your agent still does the work, in your systems, with your credentials.

[Build your first map, free](https://app.maplith.com/login) · Try the sandbox

Why your agent needs a map

## Every task starts from the map, not from zero.

Without a map, every task starts from zero

- Find where the data lives, in systems it has never seen.
- Guess how those systems join. Models miss joins: asked to guess, a model found 4 of the 10 joins that measurement finds in our test company’s exports.
- Read raw exports to answer one question — about 26,900 tokens on an earlier synthetic test company, again every session.
- Remember what it already handled.
- Work out whether it may act.
- Write down afterwards what it did.

With Maplith, it starts from the map

- **The map** — where things are and how they connect, every join it could test measured against your own rows.
- **Signals** — what needs doing: what changed since the last scan, and the rules you wrote, judged per product, per order.
- **Task context** — one call with what a signal touches, the verified route between systems, your playbook, and what the agent may do.
- **The action gate** — allowed, pending or denied before it acts; a person approves what you say needs one, and every decision is logged.
- **Live rules** early access — Maplith compiles what to check live from your map; your own AI or no-code automation runs the small checks and reports back only what it saw, and Maplith turns that into a signal with its task context within minutes. Being built now.

Fourteen tools that answer

## Small answers to precise questions.

| Tool | What it answers |
| --- | --- |
| get_map_overview | domains and objects; rows per object; counts of fields, relations, findings, metrics and processes; a quality summary — orientation |
| get_object | full object: how many rows and what one row is; fields with their role — identifier, dimension, measure or attribute — and personal-data classification; relations with verified joins; related findings |
| search | objects, findings, processes and metrics matching a term, with ids for fetch |
| fetch | one document by id — object, finding, process or metric — in the shape ChatGPT connectors expect |
| get_process | the processes discovered from the dates in your exports; one in full with its happy path, median times and deviating variants |
| get_metric | grounded KPIs — every number verified against map fields; one in full with its formula, exact {object, field} grounding, and every caveat |
| list_findings | documented discrepancies with evidence and lifecycle |
| list_sources | the systems and files the map was built from: format, record count, when each was last read, the objects built from it, and what your team stated about each system — owner, refresh cadence, retention, access — or that nobody has yet |
| list_signals | what changed since the last scan, as typed events with a severity — the pulse to poll instead of re-reading the map |
| list_automations | the automations your business already runs, bound to the objects they read and write — the ones that never ran or last failed first |
| get_task_context | everything needed to act on one signal in a single call: objects, join paths, process step, findings, metric, what was done last time — or, for a support case, where to look the customer up, the playbooks for it and what the key may request |
| get_value_summary | what your workspace got over a period: signals raised, acted on, not acted on or needing none, time to action, actions by outcome, requests through the gate, and the value your agents stated — counts, never an estimate |
| route | the shortest verified join path between two objects: keys, rates, caveats, systems, PII on the way |
| ask | one question in plain language, answered from what the key may see, with citations to the map elements it rests on and what the map could not establish |

The pulse

## Your agents poll what changed — including the rules you wrote.

Every scan writes what changed as typed events: a finding that appeared, a process step that slowed, a tracked number that crossed the line you drew, a connection that stopped answering. Your agents poll `list_signals` instead of re-reading the map, and `get_task_context` returns everything one of those events needs — the objects, the join paths, the process step, the open findings, what was done last time — in a single call.

Or Maplith wakes your agent when something moves: a signed call to an address of yours, naming signal ids and nothing else, within limits a person sets. Once your organisation has accepted the current Data Processing Agreement, wake-ups start as soon as you set your agent up, and an admin can turn them off. [How wake-ups work](https://maplith.com/docs/wake-your-agent).

On top of that you write your own conditions. An admin builds a rule in Rules & know-how › Rules from the map’s own names — “stock is zero and ad spend over the last day is above zero, per product” — and every scan judges it per group as it finishes. A group the rule holds for becomes a `rule_fired` signal carrying the figure behind each condition; when a group stops matching, the rule records the clear and answers its signal; a rule the map can no longer answer becomes `rule_broken`, with the reason and the steps that repair it. A group is reached only through joins Maplith tested against your own rows, so a rule on a guessed join is refused when you save it, with the hop named. A rule may name the operation to suggest, and that is a hint: the agent still asks with `request_action` before it acts.

A rule’s signals list_signals

**rule_fired**

a group the rule holds for, with the figure behind each condition

**rule_broken**

a rule the map can no longer answer, with the reason and the steps that repair it

### The first evaluation is a baseline

A rule’s first evaluation is its baseline and fires nothing: the groups that already hold are recorded and raise no signal, so saving “stock is zero” does not announce every product that was already sold out. After that a group that starts holding fires, and a baseline group that stops holding and later holds again fires; one that has never stopped holding stays quiet. No figure per group is stored either way — the baseline keeps only a hash of each group that held, never its name, and a firing is a signal with the figures that made it true, not a copy of your rows.

### Metrics you define

Metrics work the same way from the other end: besides the ones the map proposes, an admin can define a formula of their own on the Metrics page, and it is measured, watched and served to your agents like any other.

### Live rules

early access

Early access, being built now: live rules. Today a rule is judged when a scan finishes, or on its own daily or weekly schedule for a connected system. With live rules, Maplith compiles what to check live from your map, your own AI or no-code automation runs the small checks and reports back only what it observed, and Maplith turns the observation into a signal with its task context within minutes. The data and the automation stay yours; Maplith holds the logic.

Playbooks

## How your business handles it, handed to the agent.

A playbook is the way your people handle something — the steps, the checks, the exceptions, the tone — bound to the signals, operations or processes it applies to. Admins write them, or Maplith drafts one from a procedure you upload with your exports; a draft is marked as Maplith’s words and nothing uses it until an admin puts it in use. Your agents receive the playbooks that fit inside `get_task_context`, and any MCP client can list them as resources, get them as prompts, or load them as a skill file. A playbook is guidance, not enforcement: what an agent may do is decided by the key’s policy when it asks.

Eight tools that act

## Writing is a policy, not a permission slip.

Every key is read-only unless you choose more — when you create it, when you approve a connector such as ChatGPT or Claude, or later in Settings — to `act_with_approval`, where a change to a finding’s status waits for your explicit decision, or to `autonomous`, where it applies immediately. The others sit either side of that line: taking a signal and recording what an agent did change nothing in your systems, so an approval key may do both itself — except that closing a signal as “not an issue” or “won’t fix”, which keeps it quiet, waits for your decision too — and turning a metric’s tracking on or off, or registering an automation, is `autonomous` only. Below that, the write tools do not exist for the key at all: they are absent from `tools/list`, so an agent cannot even try.

1. Read-only The default for every key; the write tools are absent from tools/list. read_only
2. With your approval A change to a finding’s status waits for your explicit decision. act_with_approval
3. Autonomous The change applies immediately. autonomous

| Tool | What it does |
| --- | --- |
| correct_source_system | correct uploaded system groupings: move files, split, merge or rename systems, kept across later uploads. Whole-map autonomous keys only |
| answer_question | answer a question Maplith asked about your data, one kind per signal: what a new export’s unrecognised columns are, which columns identify a row of a file, whether a headerless schema is PostgreSQL or MySQL, or which of two copied files holds the original — only what you checked in your own systems; a person’s answer always stands |
| update_finding_status | move a finding through its lifecycle — with an approval key the change waits for your decision, and every use is logged |
| configure_metric | ask Maplith to record a metric over time, so it can say when the number moves — autonomous keys only |
| register_automation | record an automation your business runs — a flow, a zap, a scheduled job — against the objects it reads and writes, and report how it is running; every name is checked against the map. Autonomous keys only |
| take_signal | say an agent is working on a signal, so no other agent does the same work — held on a lease that runs out if it never reports back; an approval key may take one itself |
| record_action | tell Maplith what was done about a signal and what came of it — fixed, not an issue, or won’t fix — or how an allowed request_action ended, so the next scan knows what a recurrence means and the action log shows the outcome. An approval key may record a fix itself; “not an issue” and “won’t fix” keep a signal quiet, so from an approval key they wait for your decision |
| state_relationships | tell Maplith how your files relate — keys, join tables, keys across systems — so every scan checks each against the data, prefers the ones that hold over its own guess, and asks you about the rest. Autonomous keys that see the whole map only |

Every action lands as a durable audit row — actor, target, cost — visible in your workspace. The same policies govern agents Maplith hosts for you: they open pull requests, never merge.

One tool that asks first

## Your agents act in your systems. You decide what they may do.

Declare the operations your agents carry out — pause ad spend, create a purchase order, issue a refund — and set per key whether each needs a person’s approval, which amounts are always a person’s decision, and how many a day are allowed. Before it acts, the agent calls `request_action` and gets `allowed`, `pending` or `denied`; anything a key has no policy for is denied, and every decision is logged. Maplith never holds the credentials to those systems and never performs the action: your agent does, with your credentials, when the answer is yes. A request that waits for a person is approved or denied by a workspace admin in Agents & access › Activity, re-checked against the key’s policy at that moment; no agent can approve one. An allowed answer also carries a short-lived grant, signed by Maplith and good once, for that request. If you run an executor — the small piece of your own code that holds the credentials — it refuses any action that comes without a valid, unspent grant, so the refusal happens where your credentials are. Without one, the gate advises cooperating agents: an agent that never asks is not stopped.

request_action before the agent acts

**allowed**

carries a short-lived grant, signed by Maplith and good once

**pending**

a workspace admin approves or rejects it in Agents & access › Activity

**denied**

anything a key has no policy for

One tool that asks

## When the answer is not in the map yet.

An agent that cannot answer your question because Maplith lacks the capability can say so where it counts: `suggest_feature` files the request as an issue in Maplith’s own tracker and hands the agent the URL, so you can follow it. It is explicit — nothing is filed unless the agent chooses to — and it is not on the policy ladder, because it changes nothing in your workspace. If an open issue already asks for the same thing, the agent gets that issue instead of opening a second one.

| Tool | What it does |
| --- | --- |
| suggest_feature | ask for a capability Maplith does not have — it becomes an issue in our own tracker and the agent gets the URL back |

The text an agent sends goes through best-effort masking, sanitising and truncation before it is filed, and the tool tells the agent to describe the capability rather than your data. A few suggestions per workspace per day, each one a durable audit row like any other agent action. The public demo key cannot file at all.

Scoped access

## Keys that know their place.

Every agent key is scoped — by domain, or down to single objects — and the scope is enforced on every call. Keys are revocable in one click and stored as hashes. Personal data is first-class: every field carries a `personal` classification — contact, identity, financial, special category, other, or none, with where the verdict came from and how sure it is — set by the scan from the column name and the shape of its values and corrected by you, plus a `pii` flag that is true for any category but none; the connection instructions tell the agent how to treat flagged fields. The map is metadata — your files are deleted after every build — but findings quote evidence and descriptions can quote example values. Maplith tries to mask email addresses, Danish CPR numbers, IBANs and card numbers before storage — a best-effort safeguard, not a guarantee — and the names of people from your export’s own name columns, on by default. A name found only in free text, and a phone number other than one a helpdesk export declares on a contact, are not masked unless you add them as masking terms.

personal on every field

- contact
- identity
- financial
- special category
- other
- none

pii is true for any category but none

Live sandbox

## Try it against a real map, right now.

Acme Commerce, a fictional web shop — 19 objects, 50 relations, 17 findings — served by the same production MCP your workspace would use. Read-only demo key, rate-limited.

Then ask: “call get_map_overview” · “get_object support_conversation” · “which findings mention refunds?”

```
claude mcp add maplith --transport http https://app.maplith.com/api/mcp \
  --header "Authorization: Bearer mlk_demo_acme-ltyWYChCrYzO8KOec-8BX-yO"
```

**A real response, captured from this sandbox on 2026-10-24**

```
{
  "map_built": "2026-10-24T03:41:18.184+00:00",
  "scope": "full map",
  "objects_by_domain": {
    "Communication": ["support_admin", "support_team", "conversation_part", "support_conversation", "conversation_tag_assignment"],
    "Supply Chain": ["sku_catalog", "purchase_order", "supplier", "purchase_order_line"],
    "Finance": ["refund"],
    …
  },
  "field_count": 160,
  "relation_count": 50,
  "finding_count": 17,
  "metric_count": 60,
  "process_count": 4,
  …
}
```

## The agents come after — and then they work.

[Build your first map](https://app.maplith.com/login) · Try the sandbox