Skip to main content
Glama
Sign In

Ilu Rennik

by com.ilurennik
OverviewDiscussionsAdmin

Change something

change
Destructive

Fix a fact on file: a new address, a changed policy number, a renamed account. Use this when the person corrects, replaces, removes, moves or renames something already on file, or answers an open question. Do not use for adding something new; that is keep. Changes one thing the owner keeps here, by the id a read returned. do: restate (value is the whole fact as it now stands: the sentence on file with only what their words change changed, every other detail kept; their message is the receipt; history kept), retire (off file, kept as history), move (value is a shelf, Your vault, "off ", sealed or normal), refile (value is what it really is, such as health insurance), confirm (still right), rename (value is its new name), answer (value is their exact words answering an open question; a question about two facts that share a last four also takes verdict), drop (a Get set up question they want off their list), share and stop_sharing (see do). 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": "change"
  }
}

Input Schema

NameRequiredDescriptionDefault
doYesrestate replaces what it says, keeping history. retire takes it off file, kept as history. move puts it on another shelf, in their vault, or off a shelf. refile says what kind of thing it really is. confirm says it is still right. rename gives it a new name. answer answers an open question. drop takes a Get set up question off their list. share puts a thing they have, by its id, on the side they share with the person they share with, `keep_back` naming its facts that stay theirs alone. stop_sharing ends sharing with that person, on their yes once asked, and takes no id.
idNoThe thing's id, as a read returned it. Every do but stop_sharing.
partNoWhich part of a long answer to read: the answer's `next_part`. Leave it out for the first.
thingNoThe thing the fact is on, by id, when known; a fact on a different thing is not changed.
valueNorestate: the whole fact as it now stands, the sentence on file with only what their words change changed ("My dentist is Dr. Omar Haddad at Fernwood Dental, phone (555) 010-9999"). answer: their words. move: the destination or "off <shelf>". refile: what it is.
wholeNorestate only. `value` is the entire fact; nothing from the old sentence is carried. Leave it out to keep details `value` did not change as well.
wrongNoWith this_one_wrong or same_thing, the id of the fact that is wrong, from the question's facts.
verdictNoanswer only, on a question about two facts that share a last four. both_right: two things, both stand. this_one_wrong: `wrong` is the fact that does not end in those four; only the number comes off it and it stays on file. same_thing: one thing on file twice; `wrong` is the copy that comes off. Retire only when they say the thing itself is not theirs, never because its number was wrong.
names_itNoretire or restate, when a number they gave is on more than one thing: their own words, copied exactly from their message, that name which thing ("my BofA card").
keep_backNoWith do share: ids of the thing's facts that stay theirs alone ("but not that I'm thinking of selling").
new_thingNoThe thing's name, when no id is known: two things that could be it change nothing.
identifierNoThe number that names the thing, as said.
owner_saidYesThe 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.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag destructive=true, non-idempotent, closed-world; the description adds real behavioral context on top: history is retained after restate/retire, only one thing changes per call, changes are keyed to an id obtained from a read, and `owner_said` acts as a receipt. It stops short of disclosing auth requirements, failure modes when an id is stale, or what a call returns, and offloads share/stop_sharing behavior to 'see `do`'.

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?

Front-loaded correctly with the operation summary and the `keep` exclusion, but the middle collapses into a long semicolon-chained enumeration of `do` values that duplicates the schema and is hard to scan. Several parenthetical asides could be trimmed without loss.

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 13-parameter mutation tool with no output schema, the description supplies the lifecycle model (history kept, retire vs retire-because-not-theirs), the routing rule against `keep`, and the receipt requirement on `owner_said` — enough for correct invocation in most cases. Gaps remain around share/stop_sharing specifics and what happens when identifiers are ambiguous beyond the brief 'two things that could be it change nothing'.

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 description coverage is 100%, so the baseline is 3; the description still adds value by explaining cross-parameter intent, e.g. restate's value being the whole sentence with only the changed detail altered, and the verdict/wrong pairing for questions about two facts sharing a last four. It largely restates the enum meanings already in the schema, which caps it below 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?

Opens with a concrete verb-and-resource framing plus examples ('Fix a fact on file: a new address, a changed policy number, a renamed account') and explicitly demarcates scope ('Changes one thing the owner keeps here, by the id a read returned'). It also distinguishes itself from a named sibling ('Do not use for adding something new; that is `keep`'), so an agent can pick it without opening the 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 an explicit trigger set ('when the person corrects, replaces, removes, moves or renames something already on file, or answers an open question') and an explicit exclusion with the correct alternative named (`keep` for additions). The `do` list further routes each intent to a specific operation and notes stop_sharing takes no id.

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

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