Skip to main content
Glama

Record what you did

record_action

Record finished work; it changes nothing in your human's systems and starts no scan. Choose signal_id, request_id for your own allowed request, or work for work with no signal/request. With work: pass kind, map objects with non-personal references, the system you did it in and optional at, plus summary and outcome done or skipped; never message text or personal values. It is news in agent activity, not a signal. With a signal: pass its signal_version and episode; done/skipped needs resolution fixed, not_an_issue or wont_fix (the latter two wait for a person under an approval key, unless it is a delegate). needs_human hands the signal to a person; task says exactly what they do next. A person's hold is settled by that person or an admin's delegate key (not customer reports, security, secrets, legal). Use update_finding_status to change a finding's status instead. Summary is at most 500 characters; Maplith tries to mask it, best effort. State value only in your human's or their systems' own numbers, never estimate it. Details: maplith://docs/mcp. Needs: a key that may act with approval or autonomously.

Input Schema

NameRequiredDescriptionDefault
taskNoWith needs_human: what the person does next, whole — the exact change (where, from what to what, why, how to check) or the reply to send. A task, not an approval. Max 2,600 characters, no secrets. Recorded again on a signal waiting on your task, it updates that task.
workNoWork with no signal/request; object names exactly as the map shows. References name things (edition, page, order), never people. Repeats can become a draft for an admin at the next scan. No task, resolution, episode or signal_version.
linksNoWhere the work landed, if anywhere a person can open.
valueNoWhat this action was worth, in your human's own numbers, when they or their systems state it — the ad spend stopped on a sold-out product, the refund avoided. Only a stated figure: never estimate one. Leave it out when nothing states it; an action without a value stays unstated and is counted as such in get_value_summary.
episodeNoThe episode you worked on, as list_signals or get_task_context returned it. If the signal has since closed and come back as a new episode, nothing is recorded and you are told so.
outcomeYesWith work: done or skipped, without a resolution. On a signal, done: settled (with a resolution). needs_human: you got as far as you could; a person decides, and task says what they do next. skipped: it turned out not to matter (with a resolution).
summaryYesOne or two sentences on what you did. Max 500 characters.
signal_idNoThe signal from list_signals or get_task_context. Leave it out when you pass request_id.
task_typeNo'reply' for a drafted reply; default 'change'.
request_idNoThe request_id request_action returned, when this is the outcome of a request you were allowed (or approved) to carry out. Only your own key's requests. If the signal the request named is gone or no longer readable by your key, the outcome is recorded against the request alone and no signal is closed; if that signal still waits for work, it is handed to a person, so no other agent repeats it.
resolutionNoWhat came of it — required with outcome 'done' or 'skipped' on a signal that is not settled yet. If you cannot say, record outcome 'needs_human' instead, so a person decides.
signal_versionNoThe signal's created_at exactly as list_signals or get_task_context returned it, so Maplith knows which version of the signal your summary is about. When recording a signal, a key limited to part of the map must send signal_version: if you leave it out, or a scan re-stamped the signal after you read it, nothing is recorded and you are told to read the signal again. When you pass a request_id whose request named no signal there is no version to name: pass an empty string. Omit signal_version with work. Every scan that emits a signal again moves its version, whether or not anything about the signal changed, so read it again and look before you record. For a key that sees the whole map the record is still kept in those cases, but is hidden from keys limited to part of the map, and those keys keep seeing the signal as not acted: list_signals with unacted: true hands it to them until someone records against its current created_at.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / work / properties / objects / description
      Previous value: -"Object name → non-personal case reference. Also name the client or channel the work was for, never a person. Empty is a count without a process case. For a key that sees the whole map, a name the map lacks is kept as a proposal for a person, never added on its own."New value: +"Object name → non-personal case reference. Also name the client or channel the work was for, never a person. Empty is a count without a process case. For a key that sees the whole map, a name the map lacks goes on the map as auto-detected once reports name it three times over two days."
  2. Changed1 schema field changed
    • changedInput schema / properties / work / properties / objects / description
      Previous value: -"Object name → non-personal case reference. Empty is a count without a process case. For a key that sees the whole map, a name the map lacks is kept as a proposal for a person, never added on its own."New value: +"Object name → non-personal case reference. Also name the client or channel the work was for, never a person. Empty is a count without a process case. For a key that sees the whole map, a name the map lacks is kept as a proposal for a person, never added on its own."
  3. Changed2 schema fields changed
    • changedInput schema / properties / work / properties / objects / description
      Previous value: -"Object name → non-personal case reference. Empty is a count without a process case."New value: +"Object name → non-personal case reference. Empty is a count without a process case. For a key that sees the whole map, a name the map lacks is kept as a proposal for a person, never added on its own."
    • addedInput schema / properties / work / properties / system
      Added value: +{
      +  "description": "The system you did the work in, as list_sources names it or as the product writes its name. Tells the next agent where this work happens; never a link, an address or a person.",
      +  "maxLength": 60,
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / work / description
      Previous value: -"Work with no signal/request; object names exactly as the map shows. References name things (edition, page, order), never people. No task, resolution, episode or signal_version."New value: +"Work with no signal/request; object names exactly as the map shows. References name things (edition, page, order), never people. Repeats can become a draft for an admin at the next scan. No task, resolution, episode or signal_version."
  5. Changed3 schema fields changed
    • changedInput schema / properties / outcome / description
      Previous value: -"done: settled (with a resolution). needs_human: you got as far as you could; a person decides, and task says what they do next. skipped: it turned out not to matter (with a resolution)."New value: +"With work: done or skipped, without a resolution. On a signal, done: settled (with a resolution). needs_human: you got as far as you could; a person decides, and task says what they do next. skipped: it turned out not to matter (with a resolution)."
    • changedInput schema / properties / signal_version / description
      Previous value: -"The signal's created_at exactly as list_signals or get_task_context returned it, so Maplith knows which version of the signal your summary is about. Required when your key is limited to part of the map: if you leave it out, or a scan re-stamped the signal after you read it, nothing is recorded and you are told to read the signal again. When you pass a request_id whose request named no signal there is no version to name: pass an empty string. Every scan that emits a signal again moves its version, whether or not anything about the signal changed, so read it again and look before you record. For a key that sees the whole map the record is still kept in those cases, but is hidden from keys limited to part of the map, and those keys keep seeing the signal as not acted: list_signals with unacted: true hands it to them until someone records against its current created_at."New value: +"The signal's created_at exactly as list_signals or get_task_context returned it, so Maplith knows which version of the signal your summary is about. When recording a signal, a key limited to part of the map must send signal_version: if you leave it out, or a scan re-stamped the signal after you read it, nothing is recorded and you are told to read the signal again. When you pass a request_id whose request named no signal there is no version to name: pass an empty string. Omit signal_version with work. Every scan that emits a signal again moves its version, whether or not anything about the signal changed, so read it again and look before you record. For a key that sees the whole map the record is still kept in those cases, but is hidden from keys limited to part of the map, and those keys keep seeing the signal as not acted: list_signals with unacted: true hands it to them until someone records against its current created_at."
    • addedInput schema / properties / work
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Work with no signal/request; object names exactly as the map shows. References name things (edition, page, order), never people. No task, resolution, episode or signal_version.",
      +  "properties": {
      +    "at": {
      +      "description": "ISO timestamp with timezone, within the last 90 days, never future; default now.",
      +      "maxLength": 40,
      +      "type": "string"
      +    },
      +    "kind": {
      +      "description": "Short work kind, e.g. newsletter.published.",
      +      "maxLength": 60,
      +      "pattern": "^[a-z][a-z0-9_]*(?:\\.[a-z][a-z0-9_]*)*$",
      +      "type": "string"
      +    },
      +    "objects": {
      +      "additionalProperties": {
      +        "maxLength": 80,
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "description": "Object name → non-personal case reference. Empty is a count without a process case.",
      +      "maxProperties": 5,
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "kind",
      +    "objects"
      +  ],
      +  "type": "object"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / outcome / description
      Added value: +"done: settled (with a resolution). needs_human: you got as far as you could; a person decides, and task says what they do next. skipped: it turned out not to matter (with a resolution)."
  7. Added

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: masking of summaries is "best effort," not_an_issue/wont_fix waits on a person under an approval key, a mismatched signal_version records nothing, and a request whose signal is gone records against the request alone. The only gap is that the readOnlyHint=false / idempotentHint=false pair is never translated into a plain statement about retry/duplicate behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph of semicolon-chained clauses that repeats material already fully documented in the schema (resolution, episode, signal_version). The opening scope statement is well front-loaded, but the mode instructions, approval-key rules, and version-stamp warnings are run together with no visual separation, making it hard to parse at call time.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation with nested objects and no output schema, the description covers the failure modes an agent must anticipate: version mismatch, closed-then-reopened episodes, requests pointing at unreadable signals, and hold settlement authority. What it lacks is a plain statement of what a successful call returns or how a rejected call reports itself beyond "you are told."

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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 cross-parameter rules the schema cannot express: which parameters belong to the work mode versus the signal mode, that resolution is only meaningful on a signal, and that outcome semantics differ by mode. It also constrains summary length and forbids personal values in work objects.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete verb and resource plus the key negative scope: "Record finished work; it changes nothing in your human's systems and starts no scan." It also frames the record as "news in agent activity, not a signal," which separates it from the signal tools. The three input modes (signal/request/work) are named, though the density makes the core purpose slower to grasp 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes between modes: "Choose signal_id, request_id for your own allowed request, or work for work with no signal/request," and names an alternative tool with its condition ("Use update_finding_status to change a finding's status instead"). It also states prerequisites ("Needs: a key that may act with approval or autonomously") and the delegate/admin exception path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources