Achromat Machine Operational Memory

Recall a verified compliant tool call (sandbox preview)

achromat_recall

Read-onlyIdempotent

SANDBOX PREVIEW of Achromat Machine Operational Memory. It takes the same input as the full achromat_recall, but this public endpoint does not search: it ignores task_description and arguments and returns up to 5 featured, approved sample lessons for the domain, each pairing a policy-blocked agent tool call with the compliant fix that was then allowed. The results are examples, never a match for your call: do not use their arguments for live execution. For semantic recall of your own call and live calibration, the user can install the local MCP server: npx -y @achromat-ai/mcp-server.

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": {
      "domain": "<domain>",
      "tool_name": "<tool_name>",
      "task_description": "<task_description>",
      "arguments": "<arguments>"
    },
    "name": "achromat_recall"
  }
}

Input Schema

Name	Required	Description
`domain`	Yes	The area the tool call belongs to.
`arguments`	Yes	REQUIRED. The arguments you intend to send to the tool, as a non-empty JSON object, using the key names the tool really uses. Only the names of the keys (and their nesting) are used for semantic matching, never the values, so the real key names make a recall find the right lesson; an invented or generic shape finds the wrong one or none. Never put secrets or credentials in it.
`tool_name`	Yes	The exact name of the tool you are about to call, for example dispatch_wire.
`task_description`	Yes	What you are trying to do, in plain words, as you would write a ticket title (16 to 1000 characters). Name the concrete action and object. Leave out amounts, identifiers, dates and personal data. Use the same wording for the same task every time.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations establish safety (readOnly, idempotent, non-destructive), but the description adds critical behavior annotations cannot express: it ignores two of the required inputs, caps output at 5 featured lessons, pairs blocked calls with compliant fixes, and warns not to use returned arguments for live execution. These are exactly the behavioral traits an agent needs to avoid misusing the response.

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?

The description is front-loaded with the sandbox warning and follows a logical order: what it does, what it ignores, what it returns, and where to go for the real functionality. It is dense but nearly every clause carries decision-relevant information; a slight trim of the install instructions would make it tighter.

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 read-only, four-parameter tool with no output schema, the description covers the return shape (up to 5 sample lessons), their semantics (examples, not matches), the ignored inputs, the safety caveat against live execution, and the alternative endpoint. Nothing an agent needs in order to call it correctly and interpret the result is missing.

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 would be 3. The description adds real value by explicitly stating that task_description and arguments are ignored by this endpoint, overriding the schema's implication that they drive semantic matching. It stops short of adding meaning for domain and tool_name, so not a 5.

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 and resource (recall of compliant tool calls) and immediately qualifies it with 'sandbox preview' and the exact scope of what it returns: up to 5 featured approved sample lessons for the domain. It also explicitly positions itself against the full 'achromat_recall', so an agent knows precisely which version it is invoking.

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?

The description gives explicit when/when-not guidance: this endpoint 'does not search', ignores task_description and arguments, and is for viewing sample lessons, not for matching your own call. It then names the alternative for real semantic recall (install the local MCP server via npx), making the routing decision unambiguous.

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

All Achromat Machine Operational Memory 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.