Skip to main content
Glama

Ilu Rennik

Propose a fact for the owner to approve

propose
Destructive

Offer a lasting fact found during other work: an account, a policy, a membership, who acts for them. Use this when something lasting comes up during other work, such as an account opened, a policy renewed or a new membership number, or when you read a document they attached here, and they have not yet said to keep it. A booking, an appointment, an amount owed or a due date is not one, unless they ask for it. Do not use for what they already said yes to; that is keep. Puts one fact the app learned or did for the owner (an account opened, a policy renewed, a new membership number) in front of them, with the shelf it belongs on and the app's name as its source. A document read for the owner, such as one attached to this chat, goes as one thing: its name in subject and each value under it in details, up to 40, kept with one tap. source is the message it came from, shown with it. It waits under Potential facts and is on file only when the owner keeps it.

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

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.
partNoWhich part of a long answer to read: the answer's `next_part`. Leave it out for the first.
factsNoSeveral lasting facts at once, such as what a brief found that stays true, each with its own statement, shelf and source. They wait under Potential facts as one, and one yes keeps them. In place of statement.
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).
shelfNoThe shelf it belongs on, one of Money, Insurance, Home and cars, Health, Documents, Accounts, Business, Estate, People, Preferences or Travel and events; they confirm it when they keep it. One of their own goes in `also_on`.
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 it under Potential facts and kept with it as where it came from.
also_onNoOptional: one of their own shelves, by its name, to put it on as well.
detailsNoFor a document read for the owner (a blood test, a policy, a statement): each value or term as one sentence. The document is one thing, named in subject, and the owner keeps all of it with one tap.
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.
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.
statementNoOne fact about the owner's life, as a sentence: something done in their name or learned about it.
identifierNoThe number that names the thing, when there is one: a whole policy number or plate, or an institution with its last four.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

The description adds useful behavioral context beyond the annotations: the fact waits under Potential facts, is shown with its source, and is only on file when the owner keeps it. However, it does not address the destructiveHint=true annotation, duplicate or overwrite behavior, or idempotency, leaving meaningful behavioral gaps for a mutating tool.

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 purpose is front-loaded and the guidance is understandable, but the description is repetitive: 'lasting fact found during other work' and examples like an account opened or policy renewed recur several times. It could be shortened substantially without losing information.

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 complex 14-parameter tool with nested objects and no output schema, the description covers the main workflow: proposal, approval staging, document grouping, source retention, and exclusions. It does not explain return values or error behavior, but the schema carries most parameter detail and the description is largely sufficient for correct invocation.

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 parameters thoroughly. The description mostly repeats the document handling and source semantics; it adds some framing but little parameter-specific meaning beyond what is already in the schema.

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 action and resource: offering a lasting fact for the owner to approve, with concrete examples such as an account, policy, or membership. It explicitly distinguishes this from `keep` when the owner has already approved a fact, so an agent can select it confidently over the sibling.

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 clear when-to-use guidance: a lasting fact arises during other work, a document is read, or the owner has not yet said to keep it. It also states exclusions such as bookings, appointments, amounts owed, and due dates, and names `keep` as the alternative for already-approved facts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources