SetLatch

Edit a data map system

update_data_map_system

Destructive

Change a system in the data map: only the fields you pass change. Rename or re-describe it, or archive / restore it (archiving needs the owner role; archived systems get no new tasks, existing tasks stay). To add a new system use add_data_map_system.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "system_id": "<system_id>"
    },
    "name": "update_data_map_system"
  }
}

Input Schema

Name	Required	Description
`name`	No	New name.
`site`	Yes	The site: its slug from list_sites (its id or exact name also work).
`type`	No	New kind of system.
`notes`	No	Where to look and how, for whoever handles the task. Replaces the existing notes.
`archived`	No	true archives it (owner only), false restores it.
`holds_pii`	No	Whether it holds personal data; only systems that do get tasks on new requests.
`system_id`	Yes	The system id from get_data_map.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 6, 2026

addedInput schema / properties / archived / description

Added value: +"true archives it (owner only), false restores it."

addedInput schema / properties / holds_pii / description

Added value: +"Whether it holds personal data; only systems that do get tasks on new requests."

addedInput schema / properties / name / description
```
Added value: +"New name."
```

addedInput schema / properties / notes / description

Added value: +"Where to look and how, for whoever handles the task. Replaces the existing notes."

addedInput schema / properties / system_id / description
```
Added value: +"The system id from get_data_map."
```
addedInput schema / properties / type / description
```
Added value: +"New kind of system."
```

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds material context beyond them: partial-update semantics ("only the fields you pass change"), the owner role required for archiving, and the downstream consequence (archived systems take no new assignments while existing tasks persist). That is exactly the destructive-impact and authorization detail an agent needs before calling.

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

Conciseness5/5

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

Two sentences, both load-bearing, with the core partial-update guarantee front-loaded and the sibling routing placed at the end. No repetition of the title or filler.

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 7-parameter mutation tool with no output schema, the description covers purpose, side effects, and auth adequately. It does not say what the call returns or what happens on validation failures (e.g., duplicate name, unknown system_id), which would be the remaining useful additions.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented, including the owner-only archive rule and the notes-replacement behavior. The description restates the same field families (rename, re-describe, archive/restore) without adding format or constraint detail beyond the schema, so the baseline 3 is appropriate.

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

Purpose5/5

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

Names a specific verb and resource ("Change a system in the data map") and enumerates the concrete operations: rename, re-describe, archive, restore. It explicitly distinguishes itself from the sibling add_data_map_system, so an agent can route correctly without opening either schema.

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?

Gives an explicit alternative and the condition that selects it ("To add a new system use add_data_map_system"), plus the permission gate for the archive variant. The when-to-use forks (edit vs. create, archive vs. restore) are all stated rather than inferred.

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

All SetLatch tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?