Skip to main content
Glama
Sign In
griasa

griasa

by Stari-am
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Decisions

list_decisions
Read-onlyIdempotent

Retrieve decisions from recorded meetings with reasons, decision-makers, and rejected options. Search what was decided, why a choice was made, or whether an alternative was considered.

Instructions

Decisions taken in recorded meetings, newest first: what was decided, why, who made the call, the options not chosen, and the exact words it was decided in. Use for "what did we decide about X", "why did we choose Y", "did we ever consider Z". Reversed decisions are included and marked; leave them out with standing_only.

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
limitNoMost decisions to return. Default 20.
queryNoWords to look for in the decision, its reason, who decided, or the options rejected. Omit for the newest.
sinceNoOnly decisions from meetings on or after this date, YYYY-MM-DD.
personNoOnly decisions made by this person or in meetings they took part in.
projectNoOnly decisions from meetings filed under this project id, from list_projects.
standing_onlyNoLeave out decisions that were reversed.

Output Schema

NameRequiredDescriptionDefault
returnedNo
decisionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds behavior the annotations cannot: default result ordering, and the important nuance that reversed decisions are included but marked rather than filtered out.

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

Conciseness5/5

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

Two sentences with zero filler; the content inventory and ordering constraint are front-loaded, followed by usage triggers and the one filtering caveat. Every clause carries information an agent would otherwise have to infer.

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?

Output schema exists, so return-shape explanation is unnecessary, and annotations cover the safety profile. Given that, the description covers purpose, ordering, inclusion rules, and query intent — everything needed to call a six-parameter optional-filter list tool correctly.

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 baseline is 3. The description earns an extra point by clarifying the default semantics behind standing_only — that reversed decisions are present and flagged, not hidden — which changes how an agent interprets an unfiltered call. The other five parameters are left entirely to 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?

States a specific resource ('decisions taken in recorded meetings') and enumerates its contents — what was decided, why, who, rejected options, exact wording — plus the ordering ('newest first'). The shape is concrete enough to distinguish it from list_commitments or search_meetings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives three explicit natural-language triggering questions ('what did we decide about X', 'why did we choose Y', 'did we ever consider Z'), which is strong positive routing. It also states the reversed-decision default and the opt-out via standing_only. It stops short of naming a sibling tool as the alternative for adjacent needs (e.g. raw transcript lookup).

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

Deploy Server

Other Tools