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: sign in, connect it, paste one prompt. Every tool is in the MCP reference.
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.
Every task starts from the map, not 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.
- 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.
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 |
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.
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.
- 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 accessEarly 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.
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.
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.
- Read-onlyThe default for every key; the write tools are absent from tools/list.read_only
- With your approvalA change to a finding’s status waits for your explicit decision.act_with_approval
- AutonomousThe 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 |
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.
- 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
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 |
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.
- contact
- identity
- financial
- special category
- other
- none
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.
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,
…
}