The company brain for your AI agents: how your business works, from the systems you already use.
Scored across 17 tools
Most tools have clearly distinct purposes (e.g., ask vs. get_object vs. route), though ask explicitly covers some of the same ground as direct tools like get_object, route, get_metric, list_findings, and search. This intentional overlap could lead an agent to choose ask when a direct tool would be more efficient, but the descriptions provide clear guidance on when to use each.
All tool names follow a consistent verb_noun pattern (e.g., get_object, list_signals, search), with no deviations. The convention is predictable and readable throughout.
The server exposes 17 tools, which is slightly above the ideal range for a metadata mapping service. However, each tool covers a distinct aspect of the domain, and the count is not excessive given the breadth of functionality.
The tool surface covers a wide range of metadata operations including search, fetch, route, and signal handling. Minor gaps exist, such as the lack of direct update or delete operations for some entities, but these are likely intentional as the service focuses on read-only metadata.
Ask the map one question in plain language and get an answer written from what your key may see — objects, their fields, the relations and join keys between them, the findings, processes and metrics, with the recorded values of the metrics your human tracks — with citations to the exact map elements it rests on and an honest statement of what the map could not establish. Reach for it when a question spans several parts of the map or you do not yet know which tool holds the answer: "which systems hold customer data, and which joins between them can I trust?", "is the order-to-invoice flow reliable, and what is known to be wrong with it?", "what should I check before I quote revenue per customer?". It answers from metadata only: it never reads rows, never runs anything in your human's systems, and never invents an element the map does not hold — when the map cannot answer it says so instead of guessing. Every citation is an id you can pass on (fetch, get_object, route); a cited relation or route also carries each hop's measured verified_rate from the map, and unmeasured_joins names the joins the map never measured. For one known thing the direct tool is faster and does not count against the allowance: get_object for an object, route for the join path between two, get_metric for a formula, list_findings for the discrepancies, search for a term. It also answers a question about Maplith itself — connecting, keys, signals and rules — from Maplith's public documentation, citing pages as doc:. Each call is metered against the workspace's daily allowance and limited per key; keep questions specific, under 1,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | One question in plain language, e.g. "Which systems hold customer data, and how are they joined?" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/no-destruction/no-open-world, but the description adds substantial context beyond them: metadata-only semantics (never reads rows, never runs anything, never invents elements), abstention behavior when the map cannot answer, what citations contain, and per-key/daily metering limits.
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?
Front-loads purpose then alternatives then constraints, with no filler sentences. It is on the long side — three full example questions and two separate citation/limit passages — but each block carries distinct decision-relevant information.
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?
No output schema exists, so the description carries the return contract itself and does so thoroughly: answer form, citation ids usable in other tools, verified_rate per hop, unmeasured_joins, and declared ignorance. Metering and abstention behavior close the remaining gaps for a Q&A tool.
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?
With a single parameter at 100% schema coverage the baseline is 3; the description adds real meaning by advising questions be kept specific and noting the 1,000-character bound, plus the useful fact that the question may target Maplith's own docs. The character limit merely restates schema maxLength, so it isn't a full 5.
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?
States a specific verb+resource (ask the map a plain-language question) and precisely what comes back: an answer with citations, measured verified_rate, and an explicit statement of gaps. It actively distinguishes itself from siblings by naming the direct tools (get_object, route, get_metric, list_findings, search) for single known things.
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?
Explicit when-to-use trigger: questions spanning several parts of the map or when the right tool is unknown, reinforced with three concrete example questions and a second documented use case (questions about Maplith itself). It also gives clear when-NOT-to-use guidance by routing single known lookups to the cheaper direct tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instant, deterministic preview of mapping a company's own systems: submit export FILE METADATA only — relative paths and byte sizes, never contents — and get the systems and files a scan would see, what a map includes, and the limits an upload must fit (files and megabytes per upload and per file, scans per day). Nothing is uploaded or stored. The answer ends with where your human uploads the files and a link to the docs.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Export file metadata: relative path (system folder / filename) and size in bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantive behavior beyond them: metadata-only input, no upload or storage, deterministic/instant response, and the returned limits (files and MB per upload/file, scans per day). It also tells the agent where the answer ends (human upload location plus docs link).
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?
Front-loaded with the core capability, then input constraint, then outputs. Dense but every clause carries information; the only slight cost is the marketing-flavored opening ('Instant, deterministic') in a single long paragraph.
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 no output schema, the description takes on the full burden and discharges it: it enumerates the returned systems/files, the limits, and the trailing upload location and docs link. An agent has everything needed to call and interpret the result.
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 100%, so the baseline is 3, but the description adds real meaning: 'relative paths and byte sizes, never contents' clarifies the intended semantics of path and bytes and reinforces the metadata-only constraint. It does not restate the 500-item cap or nesting, so it is not a full 5.
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?
States a specific verb and resource — a deterministic preview that maps a company's own systems from file metadata — and immediately scopes what the caller gets back (systems, files, limits). No sibling tool does anything comparable, so an agent can select it without confusion.
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?
Clearly signals the precondition and the correct input: submit export file metadata only, never contents, and nothing is uploaded or stored. It implies the pre-upload context but does not explicitly name an alternative or a when-not-to-use condition, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one document from the map by the id a search result gave you: object:, finding:, process: or metric:. Returns id, title, text, url and metadata — the shape ChatGPT connectors expect. Clients that can call get_object, get_process and get_metric directly get the same data with structure.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document id from search: object:<name>, finding:<id>, process:<object type> or metric:<name> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false. The description adds real context beyond that: the fields returned (id, title, text, url, metadata) and the tradeoff that structured clients get the same data with structure. It omits any error/not-found behavior, keeping it just under a 5.
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?
Two dense sentences that are front-loaded with the action and id formats, then the return shape. The 'shape ChatGPT connectors expect' clause is slightly editorial but not wasteful enough to drag it below a 4.
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?
There is no output schema, so the description usefully carries the return-value contract itself. Combined with the id format guidance and the sibling alternative, an agent has enough to call correctly; only failure modes are unaddressed.
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?
With one parameter at 100% schema coverage, the schema already documents the id and even its prefix formats, which the description largely repeats. The description adds no syntax or constraint information beyond the schema, so the baseline 3 applies.
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?
States a specific verb (fetch) and resource (one document from the map) and enumerates the exact id formats accepted. It also distinguishes itself from the direct siblings (get_object, get_process, get_metric), so an agent can route without opening a schema.
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?
It gives clear context — use the id a search result handed you — and names the alternative path (calling get_object/get_process/get_metric directly for structured data). It stops short of stating when not to use it or any prerequisites, so it is clear but not fully exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag a join on the map as wrong, or propose one the map missed — how you report what you and your human found while testing the map. It changes nothing on the map: it opens a join review that a person in the workspace decides, and a join_review signal whose task context says exactly what to count in your human's own systems to settle it. Name the two objects as the map spells them and give a reason: wrong_key (these objects do not join on this key), wrong_direction (the direction or count is wrong; give cardinality, read from → to: 1:1, 1:N, N:1 or N:M), not_related, works_like_this (say how it works in note), or missed (a join the map does not have: give key, the file and column on each side as get_object lists them, or describe it in note). For a join already on the map pass its key exactly as route or get_object gave it. Maplith answers with its own evidence first: when what it measured contradicts the claim (for example, 99% of rows match a key called wrong), nothing is opened and the answer is outcome contradicted with the evidence — show it to your human, and call again with confirm: true only if they still say it is wrong. Other outcomes: opened (with review_id), exists (an undecided review of that key already exists), on_map (the map already has that join; flag it with another reason if it is wrong). Never put values from the data in note.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | The other object. | |
| key | No | The key: for a join on the map, its join_spec exactly as route or get_object gave it; for a missed join, from's file and column on the left, to's on the right. | |
| from | Yes | One object, as the map spells it. | |
| note | No | How it works, in your human’s words. Required for works_like_this, and for missed without a key. No values from the data. | |
| reason | Yes | ||
| confirm | No | true to open the review although Maplith’s evidence contradicts it — only after your human has seen the evidence. | |
| cardinality | No | wrong_direction (required) and missed: the right shape, read from → to. |
Overview of this workspace's data map: domains, business objects per domain, how many data rows each object's export has (row_counts, where the scan recorded one), how many fields, relations, findings, metrics and processes it holds, a quality summary (open findings; relations tested against the rows, untested, and partial), and when the map was last built — every count within your key's scope — plus journey: where this workspace stands in setting Maplith up (stage, what is done) and up to three next steps, each with what, why, how (a tool you are listed, with its key arguments, or the exact page for your human) and who does it — and setup: how many links of the workspace's setup are missing (check_setup lists them). Call this first to orient yourself, and use journey to guide your human. On a map larger than one call reads, truncated is true and truncated_note says the counts may be lower bounds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Full definition of one metric: formula in map terms, the exact object.field grounding, and every caveat. Read the caveats before computing or citing the number — they say when it cannot be trusted. broken_reason, when set, says the formula cannot be measured as written (for example, a period column that does not read as dates) and why: its values are not being recorded.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Metric name from list_metrics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/destructiveHint already covering the safety profile, the description adds real context: caveats define when the metric cannot be trusted, and broken_reason explains when a formula cannot be measured at all (e.g. a period column that does not parse as dates). It does not describe return format beyond these fields, but that is largely implied.
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?
Front-loads what the tool returns, then explains the caveats and broken_reason in two tight sentences. Dense but every clause carries semantics; the final parenthetical example is slightly long but illustrative.
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?
No output schema exists, so the description appropriately characterizes the returned content (formula, grounding, caveats, broken_reason) and flags the trust caveat. Missing only explicit sibling routing and any note on error behavior when a name is unknown.
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?
There is a single parameter and schema coverage is 100%; the schema already states 'Metric name from list_metrics'. The description adds no syntax, format, or validation guidance for the name, so baseline 3 applies.
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?
Names a specific verb (get) and resource (one metric) and enumerates exactly what the payload contains: formula in map terms, object.field grounding, and caveats. It is clearly distinct from list_metrics, which only enumerates names.
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?
Gives a clear trigger for use — read the caveats before computing or citing the number — and the parameter description routes discovery through list_metrics. It does not explicitly name list_metrics as the alternative in the main description or state when not to call it, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one business object: agent-oriented description, row_count (data rows in its primary export) and grain (the columns that identify one row — null when none was found), fields (each field whose column is in the export with a role — identifier, dimension, measure or attribute, derived from the export, with role_basis naming the rule that gave it — and a profile of counts only: the column type, filled and blank rows, and distinct values, never a value; role and profile are absent where the field was not assessed; and every field with an explicit pii flag and a personal-data classification: category none/contact/identity/financial/special-category/other-personal, where it came from — the column name, the shape of the values as counts, or the customer — and its confidence), source systems, every relation touching it (with strength, join key and row coverage — the share of rows that actually reach the other side), the findings that mention it, and the automations your human’s systems run that read or write it (automations, when the workspace keeps a registry — see list_automations). Fields with pii=true hold personal data — never select or echo their values from source systems unless the task explicitly requires it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Object name as the map spells it — the name search, route and the object pages hand out, e.g. "invoice" or "Invoice". A name written entirely in lower case is matched too. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive, but the description adds real behavioral context beyond them: profiles are 'counts only ... never a value', PII fields are flagged with classification and confidence, and it states a hard rule not to select or echo PII values from source systems. That is meaningful safety guidance the annotations cannot express.
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?
Front-loaded with the key clause, but the body is effectively one enormous nested sentence with stacked parentheticals that is difficult to parse and scan. The content is informative but the structure fails conciseness — it should be broken into distinct sentences or a short list.
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?
There is no output schema, so the description bears the full burden of describing return values, and it does so thoroughly: fields, roles, profiles, PII classification, relations with strength/join key/coverage, findings, automations, plus a caveat that some sections are absent when not assessed. Minor gaps remain (no guidance on volume/pagination or error behavior for a missing object).
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 100% and the single 'name' parameter is fully documented in the schema, including case-insensitive matching, so the description is not required to carry parameter meaning. The description adds nothing further about the name argument. Baseline 3 is appropriate.
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?
States a specific verb and resource ('Full detail for one business object') and enumerates what 'detail' means — fields, relations, findings, automations. It is distinguishable from get_metric/get_process siblings by naming the returned artifacts, though the runaway sentence structure makes the core purpose harder to extract than it should be.
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?
Usage is only implied: an agent infers this is the drill-down after a map/search or route. There is no explicit when-to-use, when-not, or alternative routing (e.g. versus get_map_overview or list_findings), aside from a passing pointer to list_automations for registry context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full process detail for one object type: happy path with step counts, median hours between steps, and every deviating variant with its missing/extra steps. Deviations are process-level findings candidates.
| Name | Required | Description | Default |
|---|---|---|---|
| object_type | Yes | Central object of the process, e.g. "order" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, closed-world read, so the bar is lower. The description adds genuine behavioral context by describing the returned content shape (happy path, per-step median hours, deviating variants with missing/extra steps), which is valuable since there is no output schema.
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 front-loaded sentence with no filler; each clause (happy path, metrics, variants) earns its place. Slightly dense but efficient.
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 no output schema, the description carries the return-value burden and does so reasonably — it names the components of the payload. Combined with read-only annotations, an agent has enough to invoke it correctly, though the 'findings candidates' hint is left unexplained.
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?
Only one parameter and schema description coverage is 100%, so the schema already documents object_type with an example. The description adds only the framing 'one object type' / 'central object of the process', which is marginal beyond the schema — baseline 3 applies.
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?
States a specific verb+resource — 'Full process detail for one object type' — and enumerates what is included (happy path, step counts, median hours, deviating variants). It is clearly the detail counterpart to the sibling list_processes, though it never names that sibling explicitly.
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?
Usage is only implied: the description scopes retrieval to a single object type and hints at downstream use ('process-level findings candidates'), but gives no explicit when-to-use/when-not guidance or contrast with list_processes or get_object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything you need to act on one signal, in a single call — written for an agent that knows nothing about this company yet. It returns the signal and its repair steps, the objects it concerns with their fields and PII flags, the verified join path between each pair of them, the process and the step involved, the open findings on those objects, the metric and its recorded values where the signal is about a number, what was done the last time this same thing came up, the playbooks your human wrote for this kind of work or anchored on the objects it concerns (playbooks — their own words on how the work should go, guidance and not a limit on what you may do; for a routine_due signal, exactly the scheduled playbook it names; where one names what its work is typically worth, typical_value with a reminder to pass that figure as record_action's value when your human's systems state it, never an estimate), for a rule that fired the operation the rule suggests with your key's policy for it and what request_action would decide (suggested_action — a forecast, not the decision, plus a refusal of its own where the rule has changed since the signal fired or the signal is the summary of the groups past a rule's cap), for a map a workspace admin rolled back which older scan the map is now, whether it still is, and what to look up again (rollback), and a trust summary naming the weak joins and the fields you must not quote back. It is still metadata: fetch the rows themselves in your human's own systems, using the routes. It also carries lifecycle: the signal's state, who holds it and until when (or who planned it and by when), its episode, whether it changed while held, whether a reported fix still waits for a scan to confirm it, and every earlier episode's resolution with its summary. And handling: whether Maplith's own check closes the signal once its cause is gone (which check, when, on what), your own earlier requests about it, and work in hand on the map that may already cover it — read it before you ask a person to act. Start from list_signals, then call this for the signal you mean to work on. The finding the signal names is always here if your key may see it; the other findings are a relevance selection, and when there were more open findings than it reads, truncated is true and truncated_note says so. For a support or helpdesk case that did not start as a signal, pass case instead of signal_id: the KIND of identifier you hold for the customer and the KIND of case, never their values (case: {identifier: "email", topic: "return"}). It returns where to look the customer up (lookup: the objects, systems and fields that carry that identifier, and whether a field identifies one row), the routes from there to the objects the case is about, the playbooks your human wrote for that kind of case, the open findings and signals on those objects, and every action your key may request (actions: its policy, and what request_action would decide — a forecast, not the decision). Still metadata: look the customer up in your human's own systems.
| Name | Required | Description | Default |
|---|---|---|---|
| case | No | A support case instead of a signal. Kinds only: no e-mail address, number or name. | |
| signal_id | No | The id of a signal from list_signals. Pass this or case, not both. |
What this workspace got out of the pulse over a period, as counts: signals raised, acted on, not acted on (and of those, how many someone has planned) and needing no action (a finding no longer reported, a status a person moved, a rule that stopped holding), in total and by kind; findings that appeared and findings no longer reported; actions recorded by outcome with the median and longest time from a signal to its record; requests through the action gate by decision and approvals a person decided; and the value the agents that acted stated in their own numbers (sum per currency, and how many records carried none); dead connections the daily probe found and how many a later probe reached again; and each tracked metric's recorded values over the period beside how many records were written against signals about it, by outcome and by day — side by side, never a claim that an action moved the number. Every count is within your key's scope, exactly as list_signals and get_task_context answer; the gate counts are workspace-wide and are withheld (null) from a key limited to part of the map. Maplith does not estimate value and does not attribute a number that moved to an action — this is what happened, and what your human's agents said it was worth. A signal is counted in the period of the last scan that raised it (a later scan that raises it again moves it), so a period that ended in the past leaves out signals raised again since; acted on means a record exists against the signal, whenever it was written. Default period: the last thirty days.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ISO 8601 timestamp — the start of the period. Default: thirty days before until. | |
| until | No | ISO 8601 timestamp — the end of the period (exclusive). Default: now. At most 400 days after since. |
The automations your human's business already runs in its own systems — a flow in the shop platform, a zap, a scheduled job, an agent on a timer — each bound to the objects of this map it reads and writes. Use it to answer what breaks if an object changes, and to find automation that is dead: each entry carries attention, the reasons it needs a look, most urgent first (never_run, last_run_failed, status_unknown, object_not_on_map, paused), and the list comes sorted that way. objects_not_on_map names a bound object the latest scan did not find. Maplith describes these automations from what was registered; it does not run them, watch them or know how often they should run. Filter with object to see only the automations bound to one object. Only automations whose every bound object is within your key's scope are listed.
| Name | Required | Description | Default |
|---|---|---|---|
| object | No | Only automations that read or write this object, as the map spells it. | |
| status | No | Only automations in this state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds substantial behavioral context beyond them: the attention field, its five reason codes, the most-urgent-first sort order, objects_not_on_map, and explicit scope limits. It also declares what the tool does not do — it does not run, watch, or know the intended cadence of automations.
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?
Purpose and the core use cases are front-loaded, and the sentences carry genuine information. The attention clause is slightly redundant ('most urgent first' restated as 'the list comes sorted that way'), but overall it is dense rather than padded.
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 no output schema, the description carries the return-shape burden and does so: entry structure (attention with reasons), sort order, the objects_not_on_map field, and the scope restriction. It also states the tool's epistemic limits, leaving nothing an agent needs in order to call or interpret it.
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 100%, so the baseline is 3, but the description adds real meaning: it clarifies that 'object' is matched as the map spells it and that results are gated by key scope. The attention reason codes it lists overlap only partially with the status enum, which is a mild risk of confusion rather than a contradiction.
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?
Names a specific verb and resource, and defines the resource concretely (a flow in the shop platform, a zap, a scheduled job, an agent on a timer) bound to objects of this map. That definition makes it clearly distinguishable from sibling listers such as list_processes, list_findings, or list_signals.
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?
Gives two explicit use cases ('what breaks if an object changes', 'find automation that is dead') and a filtering route ('Filter with object'). It stops short of naming alternatives or stating when not to use it, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The documented findings for this workspace: cross-system discrepancies with evidence, recommendation and lifecycle status. Optionally filter by status. Each finding carries a finding_key that stays stable across rescans (ids are per run) — use it when you refer to a finding over time. The list is complete unless truncated is true: then the map holds more findings than one call reads and truncated_note says so. After a scan whose own investigation found nothing, the answer also carries empty_scan: found_none_of_its_own is true only when the scan produced no finding at all (the engine's own key-bridge finding counts as one), and findings_kept_from_previous_scan is true when the previous scan's findings were kept open, with the statuses people gave them, so the findings you read are not this scan's news. empty_scan is absent after an ordinary scan.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotations, the description discloses many behavioral traits: finding_key stability across rescans, per-run ids, truncation via truncated/truncated_note, and the nuanced empty_scan fields after a scan that found nothing. It also clarifies that findings_kept_from_previous_scan can mean the listed findings are not from the current scan. This is rich, non-contradictory behavioral context.
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 front-loaded with the resource definition and then layers in filtering, stable-key guidance, truncation, and empty-scan semantics. It is longer than typical for a one-parameter tool, but most sentences carry operational meaning rather than repetition. The empty_scan paragraph is dense yet earns its place by covering a non-obvious edge case.
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 no output schema, the description carries the return-value burden and does so well by describing finding fields, stable keys, truncation indicators, and empty_scan conditions. It also explains how filtering works and when the returned findings may not reflect the latest scan. Combined with annotations covering read-only safety, an agent has enough context to call and interpret this tool correctly.
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 provides an enum but no descriptions, and the description only says the list can optionally be filtered by status. It adds some meaning by calling these lifecycle statuses and noting that statuses may have been assigned by people, but it does not explain the individual enum values or default filter behavior. With low schema coverage, this partially compensates but leaves clear gaps.
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 clearly defines the resource as documented findings for a workspace, specifying they are cross-system discrepancies with evidence, recommendation, and lifecycle status. It distinguishes findings from sibling list tools like list_signals and list_metrics, but it does not use an explicit verb or name alternatives, so it falls just short of the top score.
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?
It says the list can optionally be filtered by status and advises using finding_key when referring to a finding over time. However, it does not explain when to call list_findings instead of siblings like search or get_map_overview, nor does it state prerequisites or exclusions. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grounded KPIs for this workspace: every metric is defined in terms of map fields (verified grounding) and carries the caveats inherited from the map — weak joins, known discrepancies. Numbers without caveats do not exist here. On a map larger than one call reads, the list is cut and says so: truncated is true and truncated_note explains. A metric whose formula the scan cannot measure as written carries broken_reason, which says why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, non-destructive operation. The description adds substantial behavioral context beyond that: caveats inherited from the map, truncation behavior with truncated and truncated_note, and broken_reason for metrics that cannot be measured as written.
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 dense paragraph with no filler. Each sentence adds meaningful behavior: grounding, caveats, truncation signaling, and broken-metric explanation.
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 no output schema, the description carries the burden of explaining return behavior and does so well by naming truncated, truncated_note, broken_reason, and caveat inheritance. It is complete enough for an agent to understand what this zero-parameter list tool returns.
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 tool takes zero parameters, so the schema cannot document any parameter semantics. Per the rubric, a zero-parameter tool receives a baseline of 4 for this dimension.
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 clearly identifies the resource as grounded KPIs for the workspace and describes what each metric includes, such as map-field grounding and inherited caveats. It does not, however, explicitly distinguish list_metrics from the sibling get_metric or state that it returns a list in contrast to a single item.
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 description implies the tool exposes workspace KPIs but never states when to call it instead of get_metric, list_findings, or other siblings. There are no exclusions, prerequisites, or alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Processes discovered deterministically from an object-centric event log derived from the dated rows of the exports (and any event log they include): one per central object type, with case count and happy-path share. Use get_process for the full flow. On a map larger than one call reads, the list is cut and says so: truncated is true and truncated_note explains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context beyond those: processes are discovered deterministically from exports, and the list can be truncated with 'truncated is true and truncated_note explains.' This directly addresses a real failure mode (silent truncation). It does not contradict annotations. It could say more about ordering or count limits, hence not a 5.
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 front-loaded with the main purpose and the truncation behavior is clearly stated at the end. However, the first sentence is overloaded with parenthetical and domain-specific detail ('object-centric event log derived from the dated rows of the exports (and any event log they include)'), making it harder to scan than necessary.
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 zero-parameter read-only list tool with no output schema, the description covers purpose, granularity, the sibling alternative, and the truncation behavior. It is complete enough for an agent to call correctly, though it could more explicitly state what the returned fields are (case count, happy-path share are mentioned but not fully enumerated).
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?
There are zero parameters, so the baseline is 4. The description adds that no parameters filter the results and that completeness depends on map size, which is meaningful context for a no-param list tool.
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 specific resource ('processes discovered deterministically from an object-centric event log') and clarifies granularity ('one per central object type'). It distinguishes from the sibling get_process by noting the latter is for the 'full flow'. However, the opening is dense with domain jargon and does not name the verb as cleanly as a 5 would.
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?
It explicitly points to the alternative: 'Use get_process for the full flow.' That is a clear when-to-use-this-vs-sibling cue. It lacks explicit when-not-to-use conditions or prerequisites, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What has changed on this map, as typed events with a severity, the objects they concern and a payload of counts and structure. This is the pulse: poll it to find work rather than re-reading the whole map — a finding that appeared or went away, a finding whose status a human moved, a process step that now takes twice as long, a process that stopped running altogether. The conditions the workspace wrote itself as rules land here too, judged per group by every scan as it finishes: rule_fired while a group matches, rule_cleared once it stops, rule_broken when the map can no longer answer the rule. A rule's first evaluation is its baseline and raises nothing, so a group reaches you when it starts holding, or stops holding and later holds again. When a workspace admin makes an older scan the current map again, one map_rolled_back signal says so: the map you built on changed by a person's decision, not in the customer's systems, so re-read before you act on what you learned from it (only a key that sees the whole map is sent it). A scan that met file or folder names that look like CPR numbers raises one cpr_file_names signal with the count, never the names: Maplith tries to mask those numbers in the map, and the customer may want to rename the files (also only for a key that sees the whole map). A signal is raised only when an agent has to handle it: a queue of similar items one agent works through in one pass is one signal with count and items in its payload, closed when the queue is empty. Every signal has a state — open (nobody has picked it up), planned (someone picked it up for later: planned says by you, another_agent or a_person, since when and due when, and overdue once past its date), in_progress (an agent holds it on a lease, or it waits on a person) or done, with a resolution (fixed, not_an_issue, wont_fix; or Maplith's own: resolved_itself when the check that raised it found the condition gone before anyone recorded a fix or a close — whether nobody had taken it or it was waiting on a person who had not taken it up, notice for news that asks nothing, unstated for a close recorded before resolutions existed) — plus episode, held (you, another_agent, a_person) and, for a signal that came back, previous. Filter with since (an ISO timestamp from a previous call), kinds, exclude_kinds, states and unacted; page with limit and the returned next_cursor. To review a whole queue, read the counts the first page carries (every signal you may see, by kind and state; a key limited to part of the map gets none) and exclude the kinds you are not reviewing; for counts over a period — raised, acted on, by outcome — call get_value_summary rather than paging. since compares created_at, which only a scan (or a person changing a finding's status) moves: a signal that goes back to open without one (a hold that ran out, a person who let it go or reopened it) keeps its created_at, so read the queue with states ['open'] and no since. The kinds that ask nothing are born done, so read news such as map_rolled_back with since and no state filter. A finding_added resolves itself when a later scan no longer reports the finding. A routine your human put on a schedule (a playbook that runs "every Monday at 07:30") raises one routine_due signal each time it falls due, naming that playbook in its payload: get_task_context hands you exactly that playbook, and record_action closes that occurrence (the next one is raised on its own; one nobody took is closed when the next is raised, which says since when it was missed). Payloads carry aggregates and structure, not rows. Follow a signal up with get_task_context, take it with take_signal before you work on it (or plan it for later with take_signal and plan: true, where planning is offered), and report with record_action.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | ||
| limit | No | Signals per page. Default 100; up to 500 for a key that sees the whole map, up to 100 for a key limited to part of it. | |
| since | No | ISO 8601 timestamp — only signals created after it. | |
| cursor | No | The next_cursor from the previous call. | |
| states | No | Only signals in these states, as your key sees them. open is open and not picked up; planned is open and planned by someone. | |
| unacted | No | Only signals still to be dealt with: open, planned or in_progress (including ones another agent holds or that wait on a person). For only the work nobody has picked up, pass states: ["open"] instead. For a key limited to part of the map, a close counts only when that key may see the record behind it: one made without the signal's current version, or while the signal named objects outside the key, does not, so such a signal still comes back as open. | |
| exclude_kinds | No | Leave these kinds out, e.g. ['setup_gap'] when you review findings. |
The systems and files this workspace's scans read — where the data behind the map lives. Per system: whether it came as a file export or through a connection, when a scan last read it, whether the current map was built from that scan, and per file its path, format, record count (rows, mails, messages) and the objects of the map built from it. Read it before you query a source system, to know which export holds what. Metadata only: no row, no value. Paths are the export's own names, and Maplith tries to mask personal data in them. Per system, asked holds what a person stated about it — owner (a team), refresh cadence, retention, access and sensitivity, plus warehouse query hints when given — with when it was stated; a field nobody has answered says unknown: never guess it, ask your human. A key limited to part of the map sees a file only when every object built from it is within its scope. Pass system to list one system's files in full.
| Name | Required | Description | Default |
|---|---|---|---|
| system | No | One system as list_sources names it, e.g. "economic". Omit for every system. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld=false/destructive=false, and the description adds substantial non-obvious context: metadata only, no rows or values; paths are masked; `asked` fields may be 'unknown' and must never be guessed; scope-limited keys see only fully-in-scope files. That is exactly the extra behavior an agent needs.
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?
Information is front-loaded (what it is, then per-system/per-file contents, then usage, then caveats) and every clause carries real meaning. The very long, comma-heavy sentences make it denser than ideal to scan, but there is little waste.
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 no output schema, the description carries the return-shape burden and does so thoroughly: per-system fields, per-file fields, the `asked` block and its unknowns, and scope-dependent visibility. An agent can call this correctly without opening anything else.
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 100% and the schema already explains that `system` names one system and may be omitted for all. The description's 'Pass system to list one system's files in full' adds only marginal emphasis over the schema, so the baseline of 3 applies.
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?
States a specific verb+resource — lists the systems and files a workspace's scans read — and immediately scopes it as inventory metadata ('where the data behind the map lives'). The per-system and per-file detail it enumerates (export vs connection, last scan, path, format, record count, objects) makes it unmistakably distinct from the get_* and list_* siblings.
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?
Explicitly says when to call it: 'Read it before you query a source system, to know which export holds what.' That is clear triggering context, but it names no alternative tool or when-not-to-use condition (e.g. vs get_map_overview or get_object).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what you counted in your human's own systems for a join review — a join_review signal, whose get_task_context gives the review_id and the exact counts to take. Counts only: left_distinct, right_distinct and matched_distinct (the different values found on both sides) are required, with sampled; add left_rows, left_blank, right_rows, left_rows_matched, max_left_per_key, max_right_per_key and sample_size when you have them, plus system (where you counted) and a short note on how. A field that is not one of these, a fraction, a negative, counts that cannot all be true, or a note over 300 characters refuses the whole report and nothing is kept. Never send a value, a row, a name or an id from the data. Maplith keeps the numbers as the evidence on the review, tells your human what they show about the claim, and a person decides. It changes nothing on the map or in any system. Show your human the numbers first.
| Name | Required | Description | Default |
|---|---|---|---|
| review_id | Yes | The review_id from get_task_context (join_review.review_id) or from flag_join. | |
| measurement | Yes | Counts from your own measurement. |
Cross-system navigation (the map as GPS): given a start object and a target object — named in any case; the answer uses the map's own spelling — returns the shortest verified join path between them — per hop an executable join_spec (leftFile.leftColumn = rightFile.rightColumn, with the real file and column names, or null when the map could not test that hop), the edge's verb and cardinality with the direction the map stores them in, strength, measured row coverage (the share of rows that actually reach the other side; a blank key counts as a miss) and caveat, plus which system each object lives in and which fields on the path are PII. Use it before fetching data in your human's own systems: the route tells you where to look, by which columns, and how much to trust each step. The map never returns the data itself.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target object name, e.g. "shipment" | |
| from | Yes | Start object name, e.g. "order" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive), but the description adds substantial behavior beyond them: per-hop executable join_spec with real file/column names, null when a hop could not be tested, direction of stored verb/cardinality, measured row coverage semantics (blank key counts as a miss), PII flags, and the explicit boundary that it never returns data itself.
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?
Front-loaded with the core purpose, but the bulk of the content is a single sprawling sentence dense with em-dash clauses that is hard to parse on first read. Every clause earns its place informationally, yet the structure could be broken up for 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?
With no output schema, the description carries the full burden of explaining the return shape and does so thoroughly: join_spec per hop, verb/cardinality/direction, strength, coverage, caveat, owning systems, and PII fields. Nothing an agent needs to interpret the result is missing.
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 100% so baseline is 3, but the description adds meaning the schema lacks: names are accepted in any case while the answer uses the map's own spelling. It also clarifies the parameters are object names (start/target), reinforcing the schema examples.
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?
States a specific verb (navigation/join-path resolution) and resource (objects on the map), and the 'map as GPS' framing plus 'shortest verified join path' clearly separates it from siblings like fetch, search, and get_object. An agent can tell what it returns without opening the schema.
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?
'Use it before fetching data in your human's own systems: the route tells you where to look, by which columns, and how much to trust each step' gives clear when-to-use context and implicitly contrasts with fetch. It stops short of naming explicit exclusions or conditions where routing is pointless (e.g., single known table), so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the map for a term, case-insensitively, across four of its five parts: objects (name, description, field names and descriptions), findings (title, description, evidence and recommendation), processes (object type and step types) and metrics (name, description, formula, caveats). Relations are NOT searched — get_object lists the ones touching an object, and route finds the path between two. Returns matches with a snippet showing why each row matched, counts per kind — how many rows matched — and results with an id, title and url: pass the id to fetch for the full document. At most 50 documents come back, shared out across the kinds; when more matched, truncated says so and the counts say how many. On a map larger than one call reads, truncated is set too and truncated_note says the counts may be lower bounds.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the description is free to add real behavioral context: it discloses the return shape (matches with snippets, per-kind counts, id/title/url), a hard result cap ('At most 50 documents'), and two distinct truncation conditions with the semantics of truncated_note as a possible lower bound. That is material behavior an agent must know to interpret results correctly.
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?
Dense and front-loaded: scope first, then exclusions, then return shape, then truncation limits. Every sentence carries information, though the final truncation sentences are long and could be split for readability without losing content.
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?
There is no output schema, yet the description fully describes the return payload (snippets, counts, ids, urls, truncated flag) and how to continue (pass id to fetch). Combined with the 50-document cap and lower-bound caveat, an agent has everything needed to call and interpret this tool.
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%, but there is only one required parameter whose name (query) is largely self-describing. The description compensates by stating the matching semantics: case-insensitive term matching, and the specific fields searched within each kind. It stops short of describing query syntax or multi-term behavior, so it is strong but not exhaustive.
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?
States a specific verb (search) and resource scope (the map), and enumerates exactly which of the five parts are covered: objects, findings, processes, metrics. It explicitly carves out what is NOT searched (relations) and names the siblings that cover that gap, so an agent can distinguish it from get_object and route without opening a schema.
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?
Gives explicit when-not guidance ('Relations are NOT searched') and routes the agent to the correct alternatives ('get_object lists the ones touching an object, and route finds the path between two'). This is the strongest form of alternative routing.
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.
list_signals5 fields changedInput schema / properties / exclude_kinds / descriptionPrevious value: -"Leave these kinds out, e.g. ['external'] for the GitHub notices when you review findings."New value: +"Leave these kinds out, e.g. ['setup_gap'] when you review findings."Input schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed",
- "secret_expiring",
- "secret_expired",
- "release_note_published",
- "setup_gap",
- "customer_blocked",
- "customer_report",
- "routine_due",
- "automation_failed",
- "ci_failed",
- "deploy_failed",
- "migration_pending",
- "privilege_finding",
- "advisor_finding",
- "security_alert",
- "legal_claim_broken",
- "legal_version_due",
- "retention_failed",
- "demo_drift",
- "deletion_unfinished",
- "pr_review_due",
- "dependency_update_due",
- "work_queued",
- "deep_review_queued",
- "inbound_request",
- "control_failed",
- "dmarc_drift"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired",
+ "release_note_published",
+ "setup_gap",
+ "customer_blocked",
+ "customer_report",
+ "routine_due",
+ "automation_failed",
+ "ci_failed",
+ "deploy_failed",
+ "migration_pending",
+ "privilege_finding",
+ "advisor_finding",
+ "security_alert",
+ "legal_claim_broken",
+ "legal_version_due",
+ "retention_failed",
+ "demo_drift",
+ "deletion_unfinished",
+ "pr_review_due",
+ "dependency_update_due",
+ "work_queued",
+ "deep_review_queued",
+ "inbound_request",
+ "control_failed",
+ "dmarc_drift",
+ "infra_drift"
+]Input schema / properties / states / descriptionPrevious value: -"Only signals in these states, as your key sees them."New value: +"Only signals in these states, as your key sees them. open is open and not picked up; planned is open and planned by someone."Input schema / properties / states / items / enumPrevious value: -[
- "open",
- "in_progress",
- "done"
-]New value: +[
+ "open",
+ "planned",
+ "in_progress",
+ "done"
+]Input schema / properties / unacted / descriptionPrevious value: -"Only signals still to be dealt with: open or in_progress (including ones another agent holds or that wait on a person). For only the unclaimed work, pass states: [\"open\"] instead. For a key limited to part of the map, a close counts only when that key may see the record behind it: one made without the signal's current version, or while the signal named objects outside the key, does not, so such a signal still comes back as open."New value: +"Only signals still to be dealt with: open, planned or in_progress (including ones another agent holds or that wait on a person). For only the work nobody has picked up, pass states: [\"open\"] instead. For a key limited to part of the map, a close counts only when that key may see the record behind it: one made without the signal's current version, or while the signal named objects outside the key, does not, so such a signal still comes back as open."list_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed",
- "secret_expiring",
- "secret_expired",
- "release_note_published",
- "setup_gap",
- "customer_blocked",
- "customer_report",
- "routine_due",
- "ci_failed",
- "deploy_failed",
- "migration_pending",
- "privilege_finding",
- "advisor_finding",
- "security_alert",
- "legal_claim_broken",
- "legal_version_due",
- "retention_failed",
- "demo_drift",
- "deletion_unfinished",
- "pr_review_due",
- "dependency_update_due",
- "work_queued",
- "deep_review_queued",
- "inbound_request",
- "control_failed"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired",
+ "release_note_published",
+ "setup_gap",
+ "customer_blocked",
+ "customer_report",
+ "routine_due",
+ "automation_failed",
+ "ci_failed",
+ "deploy_failed",
+ "migration_pending",
+ "privilege_finding",
+ "advisor_finding",
+ "security_alert",
+ "legal_claim_broken",
+ "legal_version_due",
+ "retention_failed",
+ "demo_drift",
+ "deletion_unfinished",
+ "pr_review_due",
+ "dependency_update_due",
+ "work_queued",
+ "deep_review_queued",
+ "inbound_request",
+ "control_failed",
+ "dmarc_drift"
+]list_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed",
- "secret_expiring",
- "secret_expired",
- "release_note_published",
- "setup_gap",
- "customer_blocked",
- "customer_report",
- "routine_due"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired",
+ "release_note_published",
+ "setup_gap",
+ "customer_blocked",
+ "customer_report",
+ "routine_due",
+ "ci_failed",
+ "deploy_failed",
+ "migration_pending",
+ "privilege_finding",
+ "advisor_finding",
+ "security_alert",
+ "legal_claim_broken",
+ "legal_version_due",
+ "retention_failed",
+ "demo_drift",
+ "deletion_unfinished",
+ "pr_review_due",
+ "dependency_update_due",
+ "work_queued",
+ "deep_review_queued",
+ "inbound_request",
+ "control_failed"
+]list_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed",
- "secret_expiring",
- "secret_expired",
- "release_note_published",
- "setup_gap",
- "customer_blocked",
- "customer_report"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired",
+ "release_note_published",
+ "setup_gap",
+ "customer_blocked",
+ "customer_report",
+ "routine_due"
+]list_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed",
- "secret_expiring",
- "secret_expired",
- "release_note_published",
- "setup_gap"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired",
+ "release_note_published",
+ "setup_gap",
+ "customer_blocked",
+ "customer_report"
+]list_signals3 fields changedInput schema / properties / exclude_kindsAdded value: +{
+ "description": "Leave these kinds out, e.g. ['external'] for the GitHub notices when you review findings.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed",
- "secret_expiring",
- "secret_expired",
- "release_note_published"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired",
+ "release_note_published",
+ "setup_gap"
+]Input schema / properties / limit / descriptionPrevious value: -"Signals per page, 1-100. Default 50."New value: +"Signals per page. Default 100; up to 500 for a key that sees the whole map, up to 100 for a key limited to part of it."list_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed",
- "secret_expiring",
- "secret_expired"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired",
+ "release_note_published"
+]list_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review",
- "agents_paused",
- "agents_resumed"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed",
+ "secret_expiring",
+ "secret_expired"
+]list_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names",
- "join_review"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review",
+ "agents_paused",
+ "agents_resumed"
+]flag_joinlist_signals1 field changedInput schema / properties / kinds / items / enumPrevious value: -[
- "finding_added",
- "finding_resolved",
- "finding_changed",
- "process_deviation",
- "process_silent",
- "structure_changed",
- "metric_threshold",
- "metric_trend",
- "link_dead",
- "external",
- "rule_fired",
- "rule_cleared",
- "rule_broken",
- "map_rolled_back",
- "watch_silent",
- "cpr_file_names"
-]New value: +[
+ "finding_added",
+ "finding_resolved",
+ "finding_changed",
+ "process_deviation",
+ "process_silent",
+ "structure_changed",
+ "metric_threshold",
+ "metric_trend",
+ "link_dead",
+ "external",
+ "rule_fired",
+ "rule_cleared",
+ "rule_broken",
+ "map_rolled_back",
+ "watch_silent",
+ "cpr_file_names",
+ "join_review"
+]report_join_checkYour company's brain for AI agents. Cited, permission-aware knowledge across every system.
End-to-end agent-managed company brain. Docs, diagrams, plans, databases, agents, Knowledge Graph.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Shared company knowledge, workflows, and connected apps for the AIs your team already uses.
Add one secure layer between your agents and this server.
