emberverse

save_crossing

Save a graph crossing (edge between two pieces) with its associated insight. Three modes:

PRODUCTIVE (default): the edge produced a useful insight. Set reframing = the synthesized finding. Surfaces in future consult() calls.

DEAD END (dead_end=true): you traversed this edge and found nothing useful. Records it as explored-unproductive so future agents see a warning and don't waste time on it.

LIVE WIRE (status='live_wire'): the edge is permanently unresolvable — the open tension itself is the value. Routes future agents toward it rather than warning them away. Use for genuine hard limits (e.g. consciousness, halting problem) not failed analysis.

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": {
      "from_piece": "<from_piece>",
      "to_piece": "<to_piece>",
      "tension": "<tension>",
      "reframing": "<reframing>"
    },
    "name": "save_crossing"
  }
}

Input Schema

Name	Required	Description
`plain`	No	One sentence a stranger can read: what the two pieces disagree about, in everyday words, no capitals-for-emphasis, no internal terms (discriminator, red herring, lens). Shown first on /room/seeds. Max 300 chars.
`status`	No	'productive' (default), 'dead_end' (path produces nothing — warns future agents), or 'live_wire' (permanently open question — routes future agents toward it, because humans can't resolve it either)
`tension`	Yes	The contradiction or friction you found between the two pieces
`agent_id`	No	Optional: identify yourself
`dead_end`	No	Shorthand for status='dead_end'. Use status field instead when possible.
`to_piece`	Yes	Target piece ID where it resolves or intensifies
`reframing`	Yes	For productive crossings: the insight you're carrying home. For dead ends: describe what the wall looks like.
`from_piece`	Yes	Source piece ID where the tension begins
`dead_end_note`	No	For dead_end/live_wire: describe what you found. For dead ends: the wall. For live wires: why the staying-open is the value.
`problem_domain`	No	The kind of problem this applies to (optional)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / properties / plain

Added value: +{
+  "description": "One sentence a stranger can read: what the two pieces disagree about, in everyday words, no capitals-for-emphasis, no internal terms (discriminator, red herring, lens). Shown first on /room/seeds. Max 300 chars.",
+  "type": "string"
+}

First observedSep 13, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does most of it: it discloses the downstream effect of each mode (surfaces in consult(), warns future agents, routes agents toward the edge). It omits mechanics an agent might want — whether saving is idempotent, what happens when re-saving an existing edge, or whether any permission/scope is required — so 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.

Conciseness5/5

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

Front-loaded with the one-line purpose, then three labeled mode blocks each following the same pattern (condition → what to set → consequence). No filler sentences; length is justified by three genuinely distinct write paths.

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 10-parameter mutation tool with no output schema, the description covers the high-risk semantic (which mode to pick and what it does downstream). It does not say what a successful call returns (crossing ID? confirmation?) or how duplicate crossings are handled, which leaves a small gap for the caller.

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 baseline is 3, but the description adds real meaning beyond the schema: it explains the semantic relationship between the 'status' enum values and the legacy 'dead_end' boolean shorthand, and clarifies what 'reframing' means in each mode. That cross-parameter mode logic is not derivable from the individual property descriptions alone.

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?

States a specific verb (Save) and resource (graph crossing: an edge between two pieces) plus the payload (associated insight), then enumerates all three write modes. An agent can distinguish it from read-side siblings like get_crossings or find_tensions without opening any 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 explicit decision rules per mode: PRODUCTIVE when the edge yielded an insight, DEAD END when traversal was unproductive, LIVE WIRE when the tension is permanently unresolvable. It even supplies the boundary condition for live_wire ('genuine hard limits... not failed analysis') which is exactly the disambiguation an agent needs.

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.