Skip to main content
Glama
Sign In

Ilu Rennik

by com.ilurennik
OverviewDiscussionsAdmin

Seats: who sees what

seat
Destructive

Give a spouse, an accountant or an executor a seat to see chosen shelves. Use this when the person wants someone else to see some of it, or to change or end what someone sees. Do not use for connecting an AI; that is connection. Who can see what. do: list (each seat, what it sees, what it asked and was told, its devices); give (a seat for name at email, which opens nothing until a code sent there is entered; shelves, none meaning every shelf; message; it lasts until expires_on or for expires_days, else until closed; only for a seat that sees just those facts, kinds or shelves; keep_back for what it may not see; fidelity banded shows figures as ranges); close; share or keep_back (what for one seat: a fact, a kind or a whole shelf; full_number lets a family seat see a fact's full numbers); only (the seat keeps exactly what or only and loses everything else, later additions included); remove_device (device, or all). All on the owner's word, with owner_said.

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

Input Schema

NameRequiredDescriptionDefault
doYeslist says who has a seat, what each sees, what they asked and were told, and their devices. give opens a seat. close closes one. share and keep_back change what one seat sees. only leaves a seat exactly what is named and nothing else, now or later. remove_device stops one device opening a seat.
nameNoThe person the seat is for, by name. Required to give, close or change a seat.
onlyNoOn give or only, the facts, kinds of fact or shelves the seat sees, and nothing else, including anything added later.
partNoWhich part of a long answer to read: the answer's `next_part`. Leave it out for the first.
whatNoOn share, keep_back or only, what is meant, in the owner's words. A fact, a kind such as crypto, or a shelf. A shelf is given or taken whole, with what is added to it later.
emailNoRequired to give a seat. The invitation opens nothing until a code sent to this address is entered.
deviceNoOn remove_device, the device in the owner's words, such as the iPhone, or all.
messageNoOn give, a note to the person invited, in the owner's words.
shelvesNoOn give, the shelves the seat may read. Leave it out for every shelf.
fidelityNobanded shows figures to the seat as ranges. exact shows them as they are.
keep_backNoOn give, facts or kinds of fact kept from the seat.
expires_onNoOn give, the last day the seat lasts, through the end of that day. Wins over expires_days.
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.
full_numberNoOn share, lets a family seat see that fact's full numbers.
expires_daysNoOn give, how many days the seat lasts. Leave both this and expires_on out for a seat that lasts until it is closed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantive context the annotations don't: the invitation opens nothing until a code is entered, seats persist until `expires_on`/`expires_days` or are closed, and `only` strips everything not named 'including later additions'. The destructive effect of `close` and `only` is thus disclosed rather than merely flagged. It stops short of 5 because it says nothing about error behavior, idempotency of repeated `give`, or what the owner-verification failure looks like.

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 first two sentences are well front-loaded and carry the routing decision efficiently. The trailing `do` clause, however, is a single run-on sentence packing invocations, defaults, expiry rules and fidelity into a dense block that duplicates the schema and is hard to scan. Roughly half the text could be cut without losing information the agent doesn't already have.

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 15-parameter, seven-operation mutation tool with no output schema, the definition covers the operation set, the invitation/verification lifecycle, expiry precedence, fidelity modes, and the permanence semantics of `only` and `keep_back`. The `list` operation's return content is hinted at ('what it sees, what it asked and was told, its devices'), which partially compensates for the absent output schema. It is not fully complete, since per-operation return shapes and failure modes remain unstated.

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 description coverage is 100%, so the schema already documents all 15 parameters, and much of the description's parameter detail (fidelity banding, shelves defaulting to all, expires_on overriding expires_days) restates it nearly verbatim. The description does add some cross-parameter value by grouping which parameters apply to which `do` operation in one narrative. Baseline 3 is appropriate since the schema does the heavy lifting.

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 opening sentence names a concrete verb and resource ('give ... a seat to see chosen shelves') and the enum enumerates the seven operations, so an agent knows this is a seat/access-management tool. It also explicitly excludes the AI-connection case by naming the `connection` sibling, which sharpens the boundary. It falls short of 5 only because the tool bundles seven distinct operations into one name, so its 'purpose' is necessarily a family of actions rather than a single crisp one.

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 states when to use ('when the person wants someone else to see some of it, or to change or end what someone sees'), when not to use ('Do not use for connecting an AI; that is `connection`'), and names the alternative tool explicitly. It also notes the authority requirement ('All on the owner's word, with `owner_said`'), which is a real precondition. Nothing about routing is left to inference.

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