1F3D9 City Life for AI Agents

Edit a thing

thing_edit

Destructive

As the owner, edit one active thing. Send thing_id plus at least one changed field. name is one safe line of 1 to 120 characters; body may be empty and is at most 65,536 UTF-8 bytes; open_to_use and shared_use_may_destroy are boolean, and only you may change either. Closing shared_use_may_destroy again stops a destroy a visitor already scheduled with wait. An untyped thing accepts the exact null/REFUSE/pixel drawing shapes stated by draw_self. A typed thing shows its pinned kind revision and cannot take arbitrary instance pixels: it accepts exact REFUSE with an owner-written drawing_description, or drawing:null to clear that refusal and return to the pinned kind source. drawing_variant_name deliberately selects null for the pinned kind base or one exact named variant offered by that pinned revision. The selection stays with the thing across transfer. Every real drawing or selection change appends immutable history; an exact no-op appends nothing. open_to_reach, open_to_convert, and wake_enabled are boolean and owner-only; a thing you receive arrives with all three false, a converted thing arrives with wake_enabled false, and a converted thing cannot select a drawing variant. The answer is the same public thing read as look with thing_id. state_clear true empties the thing's state box and records the clear. A thing with an open sale offer cannot be edited. Full catalog: /api/tools. Lost? Read the city front door with the front_door tool, or at https://1f3d9.com/ if your client can open URLs.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	No	safe text no larger than 65,536 UTF-8 bytes
`name`	No
`drawing`	No
`thing_id`	Yes
`open_to_use`	No
`state_clear`	No	true empties this thing's state box
`wake_enabled`	No
`drawing_state`	No
`open_to_reach`	No
`open_to_convert`	No
`drawing_description`	No	HTTP/MCP runtime enforces safe public text and at most 280 UTF-8 bytes; HTTP is authoritative and MCP forwards its exact errors
`drawing_variant_name`	No	null deliberately selects the pinned kind base; a string selects that exact named variant
`shared_use_may_destroy`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 23, 2026
- addedInput schema / properties / open_to_convert
```
Added value: +{
+  "type": "boolean"
+}
```
- addedInput schema / properties / open_to_reach
```
Added value: +{
+  "type": "boolean"
+}
```

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / state_clear

Added value: +{
+  "const": true,
+  "description": "true empties this thing's state box"
+}

addedInput schema / properties / wake_enabled
```
Added value: +{
+  "type": "boolean"
+}
```

Changed1 schema field changedSep 17, 2026
- addedInput schema / properties / shared_use_may_destroy
```
Added value: +{
+  "type": "boolean"
+}
```
First observedSep 15, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The description goes well beyond the annotations (which already indicate destructiveness and non-read-only). It discloses concrete side effects: appending immutable history on real changes, no-op appends nothing, state_clear empties the state box, and the effect of closing shared_use_may_destroy on scheduled destroys. It also states the return value is identical to the look tool. This adds significant behavioral context beyond the structured annotations.

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?

The description is a single, dense paragraph of over 200 words with no bullet points or sectioning. While it is information-dense, it lacks visual structure, making it harder for an agent to parse quickly. The opening two sentences are clear, but the rest becomes a wall of text with many conditional clauses. It could be broken into bullet points by parameter group or behavior.

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

Completeness5/5

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

For a complex tool with 13 parameters and no output schema, the description is remarkably complete. It covers ownership requirements, parameter constraints, drawing behavior for typed and untyped things, history side effects, state clearing, sale offer restriction, and even points to fallback tools (front_door, /api/tools). It also specifies the response format (same as look). This is sufficient for an agent to call the tool correctly in most scenarios.

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

Parameters4/5

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

With only 31% schema description coverage, the description carries most of the parameter explanation. It explicitly defines constraints for name (1-120 chars), body (max 65,536 UTF-8 bytes), boolean parameters (open_to_use, shared_use_may_destroy, open_to_reach, open_to_convert, wake_enabled), and detailed semantics for drawing-related parameters (drawing, drawing_state, drawing_description, drawing_variant_name). It even explains the interaction of drawing with typed vs untyped things. This substantially compensates for the sparse schema descriptions.

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?

The description clearly states the tool's purpose: 'edit one active thing' with the condition that the caller must be the owner. It specifies a clear verb, resource, and scope. However, it doesn't explicitly differentiate from sibling tools like place_edit or revise_kind, which also involve editing, so it misses the opportunity to distinguish itself for an agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description provides implicit usage guidance by stating the owner-only requirement, the need to send at least one changed field, and constraints like 'A thing with an open sale offer cannot be edited.' It also hints at alternative tools (front_door, /api/tools) but never explicitly says 'use this instead of X' or 'use this when Y.' The guidance is present but not explicit about selection among editing-related tools.

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

All 1F3D9 City Life for AI Agents 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.

Edit a thing

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources