Ilu Rennik

Keep a person

person

Destructive

People in their life: a spouse, a child, a doctor, an accountant, an executor. Use this when the person names someone in their life and who they are to them, such as their accountant, their doctor or their sister. Do not use for letting that person see anything; that is seat. Keeps a person the owner names as a fact under the person's name: who they are to the owner in the owner's words ("accountant", "sister"), or are not, with email, firm, role and notes optional. It is filed on the shelf the owner named, else on People, and a professional on their topic shelf too (an accountant on Money, a dentist on Health); one of their own shelves goes in also_on, beside it. label is what the owner called them, in their words. Named again, the same fact is updated. people takes several at once.

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": "person"
  }
}

Input Schema

Name	Required	Description
`for`	No	Who it is kept for: mine (the default) or family (them and the person they share with), when their words say so ("our son", "the kids' pediatrician").
`firm`	No	Their firm.
`name`	No	One person's name.
`part`	No	Which part of a long answer to read: the answer's `next_part`. Leave it out for the first.
`role`	No	Their role.
`email`	No	One person's email address.
`label`	No	In their own words, what this person is to them, such as lawyer, family or old friend.
`notes`	No	Anything else about them, in the owner's words.
`people`	No	Several people at once, each by name, with email if given.
`also_on`	No	One of their own shelves, by its name, to put them on as well, beside People.
`not_label`	No	What they are not.
`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.8/5.0

Behavior4/5

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

The annotations already declare destructiveHint=true and readOnlyHint=false; the description adds real behavioral context beyond them: default filing on the People shelf, automatic cross-filing to a topic shelf (accountant→Money, dentist→Health), the `also_on` side placement, and batch behavior via `people`. It also discloses the overwrite rule ('Named again, the same fact is updated'), which an agent needs given destructiveHint. That overwrite note sits in mild tension with idempotentHint=false, but it reads as an upsert with a changed timestamp rather than a direct contradiction, so no flag is raised.

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 usage rule is front-loaded, which is good, but the second sentence is a single sprawling clause packing shelf defaults, topic routing, overwrite behavior and batch mode into one line. The opening list ('a spouse, a child, a doctor...') is immediately restated in the next sentence's examples ('their accountant, their doctor or their sister'), so some content does not earn its place.

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 twelve-parameter destructive write with no output schema, the definition covers the essential unknowns: where the record lands by default, how professionals are additionally filed, how re-naming behaves, and the batch path. It leaves the caller guessing what comes back from the call and how `part` interacts with long answers, which matters a little given there is no output schema, but nothing critical to a correct invocation is missing.

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%, so the schema already documents all twelve parameters including `label`, `also_on`, `people` and `owner_said`, and the description largely restates those ('`label` is what the owner called them', '`people` takes several at once', 'one of their own shelves goes in `also_on`'). It does add genuine value by explaining the relationship between `label`, `not_label` and the shelf-routing fields, which the schema does not, so it is at baseline rather than below it.

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 the object concretely ('Keeps a person the owner names as a fact under the person's name') and gives examples of what is stored (spouse, child, accountant, executor), so an agent knows this records a person plus their relationship to the owner. It is less crisp than a single verb+resource statement because the operative verb is buried in a run-on sentence, but the purpose is unambiguous and is explicitly separated from `seat`.

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

Usage Guidelines4/5

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

It states an explicit trigger ('Use this when the person names someone in their life and who they are to them') and an explicit exclusion with the alternative named ('Do not use for letting that person see anything; that is `seat`'). What is missing is routing against the generic `keep` sibling, which can also record facts — an agent reading only this definition has no rule for choosing between them.

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?