Ilu Rennik

Settle what is waiting

read

Destructive

Yes or no to waiting facts: keep the policy found, drop the wrong address. Use this when the person says yes or no to potential facts that are waiting, such as "keep all four" or "drop the United one". Do not use for facts you showed them from elsewhere; that is keep with approved. Settles the potential facts waiting for the person's word, from files they uploaded or an agent's proposal: keep (the ids they chose, or all; they land on shelves now, in their word) or discard (the ids they refused). A keep runs only on their word. owner_said carries their message.

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": {
      "do": "<do>",
      "owner_said": "<owner_said>"
    },
    "name": "read"
  }
}

Input Schema

Name	Required	Description
`do`	Yes	keep lands the ids they chose; discard marks the ids they refused.
`all`	No	Every open proposal.
`ids`	No	Proposal ids for keep or discard.
`part`	No	Which part of a long answer to read: the answer's `next_part`. Leave it out for the first.
`owner_said`	Yes	The owner's message this call is based on, verbatim as they wrote it. It is the receipt for what is written; a quote, statement or answer passed with it must appear in it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare this as a destructive, non-read-only, non-idempotent mutation, so the safety profile is covered. The description adds useful context about keep landing ids on shelves and discard marking refused ids, plus the owner_said receipt requirement, but it remains ambiguous about what 'discard' actually does to the underlying data and does not describe return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description contains useful routing and behavioral sentences but is padded with a cryptic first metaphor and repeats the 'waiting facts' framing. It is not front-loaded with the clearest statement of purpose, though it remains readable.

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

Completeness3/5

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

It covers purpose, usage alternatives, and the core keep/discard mechanics for a five-parameter destructive mutation. However, with no output schema, it omits what the tool returns and leaves the concrete effect of discard unclear, so important gaps remain.

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

Parameters3/5

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

Schema coverage is 100% and all five parameters have descriptions, so the schema carries parameter meaning. The description reinforces `do`/`all`/`ids` semantics and the owner_said receipt but adds little beyond the schema's own explanations.

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 states a specific action: settling potential facts waiting for the owner's word by keeping or discarding them, and it names the `keep` sibling as the alternative for previously shown facts. The odd tool name 'read' and cryptic opening metaphor slightly muddy first-pass clarity, but the core verb and resource are identifiable.

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?

It gives explicit when-to-use ('when the person says yes or no to potential facts that are waiting'), when-not ('Do not use for facts you showed them from elsewhere'), and names the alternative (`keep` with `approved`). The examples ('keep all four', 'drop the United one') further ground the condition.

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

All Ilu Rennik 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.

Resources

Need Help?