Ilu Rennik

Where things stand

where_things_stand

Read-onlyIdempotent

On "Get started with Ilu": what is on file, what waits, the next offer to make. Use this when a conversation starts, when the person says "Get started with Ilu", or asks what Ilu Rennik has on them or what to do next. Do not use for looking up one thing; that is find. How their Ilu Rennik stands, in one read: stage (new, waiting or settled) and next, the one offer to make now, with suggested words to put in your own and, when it carries do, what to do before replying, in its order; each shelf with what is kept and what is waiting; every potential fact waiting for their yes (id, name, what it says, shelf, where it came from); their seats, connected apps and plan; and instructions, this server's own, for a client that did not show them. When they say no to an offer, call it again with declined naming it, and it is not made again.

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

Input Schema

Name	Required	Description
`part`	No	Which part of a long answer to read: the answer's `next_part`. Leave it out for the first.
`declined`	No	The offer they said no to, by its name in `next.offer`, so it is not made again. Leave it out otherwise; an offer they did not answer comes back in a later conversation.
`can_read_inbox`	No	True when you can search their messages yourself, with a connector of your own; false when you cannot. It decides the first offer to someone new. Leave it out when unsure.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.6/5.0

Behavior2/5

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

Rich behavioral detail is disclosed: `part` pagination for long answers, the `next` offer carrying a `do` sequence to run before replying, and that unsettled offers resurface in a later conversation. However, the statement that passing `declined` makes an offer 'not be made again' describes a persistent state change, while the annotations declare readOnlyHint=true and idempotentHint=true. The description is honest where it matters, but it discloses behavior that conflicts with the declared safety profile.

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?

Purpose and usage are front-loaded correctly, and every element describes something an agent needs. But the middle is an extremely long run-on sentence enumerating the return payload, with semicolons and nested parentheticals that make it hard to parse on first read. No output schema exists, so the enumeration is warranted, but the formatting should have been broken into a readable list.

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?

With no output schema, the description carries the burden of explaining the return value, and it does: stage/next/shelves/pending facts/seats/instructions, plus the `do` field's meaning. All three optional parameters and the zero-required-parameter calling pattern are covered, and the no-argument default (omit everything for part one) is implied clearly enough. The only real omission is any hint about size or how many parts to expect.

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%, and each parameter already has a description covering `part`, `declined`, and `can_read_inbox`. The description adds only modestly, mainly the workflow around `declined` (name the offer as it appears in `next.offer`) and that `can_read_inbox` decides the first offer for a new person — both of which the schema essentially states. Baseline 3 is appropriate.

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 read: 'what is on file, what waits, the next offer to make', and enumerates the returned sections (stage, next, shelves, pending facts, seats, instructions). It explicitly separates itself from `find` ('Do not use for looking up one thing'), which is the main sibling confusion risk. It loses a point only because the in-house vocabulary ('Ilu Rennik', 'shelf', 'seats') makes the resource partly opaque to an agent that hasn't used this server.

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 concrete triggers ('when a conversation starts, when the person says "Get started with Ilu", or asks what Ilu Rennik has on them or what to do next') and an explicit exclusion plus alternative ('Do not use for looking up one thing; that is `find`'). It also covers the follow-up case: when the person declines an offer, call it again with `declined` so the offer is not repeated.

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?