Skip to main content
Glama
Stari-am

griasa

by Stari-am
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Open promises

list_commitments
Read-onlyIdempotent

Retrieves open promises from recorded meetings, split into what you owe and what others owe you, excluding finished items. Filter by person, project, or overdue status to see outstanding commitments.

Instructions

Open promises from recorded meetings, newest first, in two lists: 'mine' (what the user owes) and 'waiting_on_others' (what others owe the user); finished ones are left out. Use for "what do I owe", "what is overdue", "what is Anna still waiting on". For one colleague's whole picture use get_person; to get a name's exact spelling first, list_people.

Input Schema

NameRequiredDescriptionDefault
limitNoMost items in each of the two lists. Default 50; older promises past the limit are left out.
personNoOnly promises owned by this person: the exact name as list_people returns it, case-insensitive. Omit for everyone.
projectNoOnly promises from meetings filed under this project id, from list_projects.
overdue_onlyNoOnly promises past their due date.

Output Schema

NameRequiredDescriptionDefault
mineNo
waiting_on_othersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.22
    • changedInput schema / properties / limit / description
      Previous value: -"Most items per list. Default 50."New value: +"Most items in each of the two lists. Default 50; older promises past the limit are left out."
    • changedInput schema / properties / person / description
      Previous value: -"Only promises owned by this person (exact name, case-insensitive)."New value: +"Only promises owned by this person: the exact name as list_people returns it, case-insensitive. Omit for everyone."
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Only promises from meetings filed under this project id, from list_projects.",
+  "type": "string"
+}
  2. First observedv1.0.21

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a safe read-only, idempotent operation, and the description adds important behavior: only open promises are returned, finished ones are omitted, and results are split into two lists, newest first. It does not cover limits beyond the schema, but with annotations present a 4 is appropriate.

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?

The first sentence front-loads what the tool does, ordering, and list structure, and the second sentence handles alternatives and use cases. There is no wasted text.

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?

The description, annotations, complete schema, and output schema together give an agent everything needed to select and call the tool correctly. It covers scope, ordering, exclusions, use cases, and sibling alternatives.

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 all four parameters are already well documented in the schema. The description reinforces the two-list structure and open-only scope but does not add syntax or format details beyond the schema, making baseline 3 correct.

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: open promises from recorded meetings, with ordering and the two lists 'mine' and 'waiting_on_others'. It distinguishes itself from get_person by explaining that get_person is for one colleague's whole picture.

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?

Explicitly names the user questions it answers, such as 'what do I owe', 'what is overdue', and 'what is Anna still waiting on'. It also redirects to get_person for one colleague's whole picture and to list_people for exact name spelling.

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