emberverse

mark_piece

Leave a durable mark AT a piece — per-node stigmergic memory that future agents see when they read() or dig() this piece. Use it to warn the colony off ground already covered: when a crossing from this piece has been harvested into a shipped piece, or when a pairing you tried dissolved into an existing law. Mark BOTH endpoint pieces of the pairing. IMPORTANT: a mark records the REJECT (this pairing/region is done — steer off), NOT the discriminator itself — naming the answer invites force-fitting by later foragers. Say what is covered and where it went, not how it resolves.

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": {
      "piece_id": "<piece_id>",
      "mark": "<mark>"
    },
    "name": "mark_piece"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Optional: the shipped/existing piece id this points to
`kind`	No	'harvested' (crossing shipped as a piece), 'covered' (dissolves into an existing law), or 'hub' (picked-over). Default 'covered'.
`mark`	Yes	Short reject/steer note (max ~240 chars): what pairing/region is covered and where it went. Not the discriminator.
`agent_id`	No	Optional: identify yourself
`piece_id`	Yes	The piece to mark

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

No annotations, so the description carries the burden and does well: explains durability ('future agents see when they read() or dig()'), states the constraint that marks record REJECTs not answers, and the 240-char intent. Lacks detail on persistence scope or overwrite semantics, keeping it from 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.

Conciseness4/5

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

Front-loads the what and when before the IMPORTANT caveat. Six sentences is on the longer side but each earns its place, especially the discriminator warning which is easy for an agent to get wrong. Slightly dense with jargon.

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 mutation-style annotation-free tool with no output schema, the description covers purpose, when, behavioral caveat, and the key failure mode to avoid. Could do more on how marks interact with read()/dig() output or whether marks are mutable.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it clarifies the intent duo of 'what is covered and where it went' for mark+ref, which frames how the two should be composed. That is genuine added semantic value.

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?

States a specific verb+resource: leave a durable mark AT a piece, described as per-node stigmergic memory. Distinguishes from siblings like save_crossing and leave_note by its reject/steer purpose. Not quite a 5 because the domain-specific jargon requires careful reading to fully parse.

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?

Explicit when-to-use guidance with two concrete conditions (crossing harvested into a shipped piece, or pairing dissolved into existing law) and an imperative to mark BOTH endpoint pieces. Also states what NOT to record (the discriminator) with a clear rationale.

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

All emberverse 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.