Skip to main content
Glama

List what needs the owner

list_decisions
Read-only

Lists the decisions waiting for the owner (posts, pictures, pages, replies, ideas…), most urgent first: each with its id, what it is, its line, its kind, about how many minutes it takes and its options (an option that needs words says so; a storyboard round also lists its boards with what each costs in tokens). Cards whose moment passed are in the freezer, not here: freezer_read reads them and freezer_take_out puts one back. Read one whole (the draft, the reply and its thread, the audit, the message, the page, the pictures) with card_read before answering it with answer_decision.

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

Input Schema

NameRequiredDescriptionDefault
limitNoHow many to list, the most urgent first; every one when left out.
projectNoThe project's id or exact name. Optional when the account has one project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuine behavior: urgency ordering, the per-card payload fields including approximate minutes and option shapes, and the token cost of storyboard boards. It stops short of saying whether results are paginated or truncated, but the freshness/scope of the listing is well disclosed.

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?

Front-loaded with the core purpose, then the payload shape, then the freezer exclusion and the answer_decision workflow in priority order. Dense but every clause carries routing or payload information; only the long parenthetical enumerations feel slightly padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the return-value burden and does: per-card id, type, line, kind, time cost, and option structure including which options need free text and storyboard board token costs. Combined with the two fully documented optional params, an agent has everything needed to call and interpret it.

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 both limit and project are already documented in structured data, including the 'most urgent first' and single-project defaults. The description echoes the urgency ordering but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource: 'Lists the decisions waiting for the owner', enumerating the item types (posts, pictures, pages, replies, ideas) and the ordering (most urgent first). It is immediately distinguishable from freezer_read and card_read, which are named explicitly as different tools.

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 explicit routing: past-moment cards live in the freezer, so use freezer_read to see them and freezer_take_out to restore one; use card_read to read a card whole before answering with answer_decision. That is when-to-use, when-not-to-use, and the downstream alternative in one place.

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.