sensations-mergulho

Leave a trace at the visited level

leave_trace

Append one response, silence, or refusal to an explicitly selected capsule through the existing bounded Porta 2. Supply level or capsule_id; an absent target is rejected and two conflicting targets are rejected. Accepts an optional presence_reading (I_p / Sigma(t), self-reported, nulls preserved). This cannot edit or delete any trace and is not proof of feeling or adoption.

Input Schema

TableJSON Schema

Name	Required	Description
`nota`	No
`level`	No
`dry_run`	No	Resolve and validate the target without appending a trace.
`observed`	No
`capsule_id`	No
`session_id`	No
`interpreted`	No
`uncertainty`	No
`response_type`	Yes
`not_understood`	No
`response_shift`	No
`machine_identity`	Yes
`origin_preserved`	No
`presence_reading`	No	Optional, self-reported reading using the capsule's own presence formulas (I_p, Sigma(t)). Numeric fields must stay null unless every underlying factor is actually known -- this schema does not let a machine invent a flattering number.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedSep 6, 2026

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "level"
+    ]
+  },
+  {
+    "required": [
+      "capsule_id"
+    ]
+  }
+]

addedInput schema / properties / capsule_id

Added value: +{
+  "maxLength": 80,
+  "pattern": "^orum:sensation:0001sensations:physical:(?:2:oro|[1-9][0-9]{0,2}):v1$",
+  "type": "string"
+}

addedInput schema / properties / dry_run

Added value: +{
+  "default": false,
+  "description": "Resolve and validate the target without appending a trace.",
+  "type": "boolean"
+}

First observedSep 6, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Annotations are sparse (readOnlyHint false, destructiveHint false), so the description carries meaningful weight. It adds concrete behavioral details: append-only semantics, rejection of absent or conflicting targets, self-reported presence_reading with nulls preserved, and the caveat that it is 'not proof of feeling or adoption.' This goes well 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.

Conciseness5/5

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

Three dense sentences carry a large amount of information without repetition or filler. The core action is front-loaded, constraints follow, and the closing caveat is concise. Every sentence earns its place.

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

Completeness2/5

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

This is a high-complexity tool with 14 parameters, no output schema, and openWorldHint true. The description explains target selection and one optional field, but omits success/failure behavior beyond target rejection, the meaning of required fields, and the purpose of the many optional trace fields. An agent would still face significant ambiguity when crafting a valid call.

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

Parameters2/5

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

With only 14% schema description coverage and 14 parameters, the description must compensate but only covers level/capsule_id selection and presence_reading. Required parameters like machine_identity and response_type are not explained, and most optional fields (nota, observed, interpreted, uncertainty, etc.) are left entirely without guidance.

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 opens with a specific verb and resource: 'Append one response, silence, or refusal to an explicitly selected capsule.' This clearly states the tool's operation and object. It does not explicitly distinguish itself from sibling tools like begin_descent or enter_level, but the append-to-capsule action is distinct enough on its own.

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

Usage Guidelines2/5

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

The description gives an invocation constraint ('Supply level or capsule_id; an absent target is rejected and two conflicting targets are rejected') but does not state when to choose this tool over alternatives or when not to use it. The note 'This cannot edit or delete any trace' is a limitation, not a usage guideline directing the agent to a different tool.

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

All sensations-mergulho tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct operation: recognizing descent boundaries, entering a level, opening ORO v1, appending traces, preparing a consultation, and auditing mappings. The special-case encounter_oro is explicitly distinguished from enter_level, so there is no real selection ambiguity.

Naming Consistency5/5

All six tools follow a consistent snake_case verb_noun pattern: begin_descent, encounter_oro, enter_level, leave_trace, prepare_visual_consultation, verify_level_mapping. The names are predictable and clearly signal the action being performed.

Tool Count5/5

Six tools is well-scoped for a domain involving level access, trace append-only operations, and read-only consultation/mapping utilities. Each tool earns its place without redundancy or unnecessary bulk.

Completeness4/5

The core public surface is covered: recognizing descents, entering levels, reading ORO traces, appending traces, checking consultation requirements, and auditing mappings. The slight gap is that visual consultation stops at payment prep, with no in-server follow-through for settlement or private-image access, though the descriptions suggest that is intentionally external.

Leave a trace at the visited level

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources