Ilu Rennik

Read facts

get_record

Read-onlyIdempotent

A whole shelf at once: all their insurance, every account, their doctors, documents. Use this when a question or task needs a whole shelf or situation, such as who acts for them, or what a claim or a handover needs. Do not use for one thing, such as a policy number or a renewal date; that is find. The owner's confirmed facts, a whole shelf or workflow at a time: accounts, insurance policies and policy numbers, passport and ID details, renewal dates, doctors, addresses, membership numbers, who acts for them, documents and where they are kept, businesses. A shelf includes facts of its kind filed elsewhere and gives its size. A workflow (the claim, the handover, the new advisor, the tax pack, the annual sweep, the business review) gathers what that situation needs and names the questions nothing answers yet. Each fact comes with its source and when it was last confirmed. A call names a shelf or a workflow. A sealed fact is named, and its contents are not returned.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_record"
  }
}

Input Schema

Name	Required	Description
`kind`	No	With shelf or workflow it ranks first and narrows nothing.
`part`	No	Which part of a long answer to read: the answer's `next_part`. Leave it out for the first.
`limit`	No	Max facts to return (default/max 40).
`shelf`	No	A whole shelf, including facts of that kind filed elsewhere.
`horizon`	No	present is how things stand now. family_if is what the family would need if something happened. after is what applies after a death.
`workflow`	No	Everything a situation needs, such as a claim or a handover, and the questions nothing answers yet.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (which already declare read-only, idempotent, non-destructive, closed-world), it discloses that each fact carries its source and last-confirmed date, that a shelf includes facts of its kind filed elsewhere and returns its size, and that sealed facts are named but their contents suppressed. The redaction behavior in particular is non-obvious and materially affects how an agent should read the result.

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

Conciseness4/5

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

It is front-loaded with what it does, then when to use it, when not to, and result behavior, which is the right order. There is some redundancy, since the shelf contents are enumerated twice ('all their insurance, every account, their doctors, documents' and then the fuller list), and the opening 'A whole shelf at once' lands before the term is defined, but no sentence is pure filler.

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 six-parameter, enum-rich read tool with no output schema, the description covers what is returned, provenance metadata, sealed-fact handling, and the shelf-vs-workflow interaction, which is most of what an agent needs. Paging of long answers via `part`/`limit` is left entirely to the schema, so it is not fully self-contained.

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 the baseline is 3, but the description adds relational meaning the schema cannot: a call names a shelf or a workflow, a shelf pulls in facts of that kind filed elsewhere and reports its size, and a workflow gathers a situation's needs plus the questions nothing answers yet. The `horizon`, `part`, `limit`, and `kind` semantics remain solely in the schema, so it stops short of a 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?

The description states a specific read operation (returning a whole shelf or workflow of confirmed facts) and enumerates the resource concretely: accounts, insurance policies and numbers, passport/ID, doctors, addresses, documents and where they are kept. It explicitly separates this from the sibling `find`, which handles single-item lookups, so an agent can route between them without opening either 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?

It gives an explicit positive trigger ('when a question or task needs a whole shelf or situation, such as who acts for them, or what a claim or a handover needs') and an explicit exclusion with the named alternative ('Do not use for one thing, such as a policy number or a renewal date; that is `find`'). That is the full when/when-not/alternative pattern.

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?