Skip to main content
Glama
Sign In

Ilu Rennik

by com.ilurennik
OverviewDiscussionsAdmin

Keep something

keep
Destructive

Keep what they tell you: a policy, an account, an address, a doctor, a note. Use this when the person tells you something to keep, hands over a note or a letter, or says yes to facts you showed them. Do not use for changing something by its id; that is change. Keeps a fact on its shelf, a note or letter whole, or a standing word on how they stand or how an AI should act. A fact goes on the shelf their words name, else on shelf, where it belongs (another is theirs to say); when two fit about equally, ask once with your guess ("Accounts, right?"), not when one clearly fits. A note goes where they said, else in their vault. owner_said is their message and the receipt; a statement they said yes to is kept with approved. facts keeps several at once, one result each; with approved, one yes keeps them all. A fact on file is corrected with change. Words already in Ilu Rennik they ask to reuse go in text, their instruction as quote. Passwords, seed phrases and full account numbers are refused.

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

Input Schema

NameRequiredDescriptionDefault
forNoWho it is kept for: mine (only them, the default) or family (them and the person they share with). family only when their own words say it is shared ("our house", "for both of us") or it is a detail of a shared thing that is not private.
kindNonote keeps a letter, a list, anything pasted or longer words they want kept whole. fact is one statement about their life (where something is kept, a number, a date, who does what), even when they call it a note; it goes on its shelf. stance is how they stand on something, or how an AI should behave.
partNoWhich part of a long answer to read: the answer's `next_part`. Leave it out for the first.
textNoTheir words, verbatim; or words already on file they told you to reuse.
factsNoSeveral facts kept in one call, each with its own `text` and, when known, `subject`, `thing` or `new_thing`, `identifier` and `paper`. With `approved`, one yes keeps every one of them. In place of `text`.
paperNoWhat the document behind a thing like this is called, when one normally exists ("the policy", "a statement", "the card"). Omit it when a thing like this has no paper (where keys are kept, a letter, a preference).
quoteNoOnly when `text` is reused from what is on file: their instruction, verbatim from this message.
shelfNoRequired for a fact: the shelf it belongs on, one of Money, Insurance, Home and cars, Health, Documents, Accounts, Business, Estate, People, Preferences or Travel and events, or Your vault if it fits none; one of their own goes in `also_on`, beside it. A shelf their words name wins. A note goes in their vault.
thingNoThe thing it belongs to, by the id a read returned (find, get_record). Omit for a new thing.
sourceNoThe message it came from, when it was found in their messages: who it is from, when, and its subject. Shown with the fact as where it came from.
also_onNoOne of their own shelves, by its name, to put it on as well.
subjectNoA short name for what the fact is about, as a person would say it ("Water bill", "Will", "Visa ending 3054"), never a person in it or the opening words of the sentence, and never a shelf.
approvedNoTrue when `text` is a statement you showed them and their message says yes to it; their yes is the receipt.
new_thingNoThe thing's name when no id is known ("Chase checking", "the Fenwick house"). One already on file by its number or name is used, and the result says which.
not_theseNoIds of things on file that a write brought back as having a name like this one, and that this is not; with `new_thing`, makes it a new thing.
identifierNoThe number that names the thing, when there is one: a whole policy number or plate, or an institution with its last four.
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.
kind_of_thingNoWhat the fact is, when plain: account_map, policy_fact, role, designation, asset_location, business_owned, letter; else instruction.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

It adds genuine behavior beyond the annotations: refusal of 'Passwords, seed phrases and full account numbers', and the instruction to ask once when a shelf is ambiguous. However, with destructiveHint=true and idempotentHint=false, the description never says what existing data a keep may overwrite or what happens on retry, which is exactly the risk an agent needs disclosed. The safety-relevant refusal policy is a real credit, but mutation/destruction semantics are missing.

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?

It is front-loaded correctly — purpose first, then when to use, then procedures. But the prose is a dense run-on with idiomatic asides ('where it belongs (another is theirs to say)') and repeated statements about shelves and `approved` that make it slower to parse than its information content warrants.

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?

For an 18-parameter, nested-object write tool with no output schema, the description covers mode selection, shelf choice, approval flow, and refusals, which is substantial. It does not describe what a successful call returns (beyond 'one result each' and 'the result says which'), so an agent cannot predict the response shape or how to handle partial failures across `facts`.

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 a 3 is the baseline, and the description earns more by explaining routing logic not in the schema: a fact goes on the shelf their words name else on `shelf`, `owner_said` is the receipt, `facts` returns one result each while one `approved` yes covers them all, and Ilu Rennik words to reuse go in `text` with the instruction in `quote`. It leaves some params (e.g. `part`, `not_these`, `kind_of_thing`) entirely to the schema.

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 names a concrete verb and enumerates the resources kept ('a policy, an account, an address, a doctor, a note') and clarifies that it persists facts on a shelf, notes whole, or stances. It distinguishes itself from the sibling `change` explicitly. The purpose is decipherable but is diffused across many sentences of in-world vocabulary ('shelf', 'standing word'), so an agent must read the whole block to grasp that this is a write/persistence tool.

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 triggers ('when the person tells you something to keep, hands over a note or a letter, or says yes to facts you showed them') and explicit exclusions with the alternative named ('Do not use for changing something by its id; that is `change`. A fact on file is corrected with `change`'). It even routes edge cases between its own modes (`facts` for several at once, `approved` for a shown statement).

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