Skip to main content
Glama

Record a decision about one of my server apps

dropyour_decision

Write down a structural decision you made for one of the owner's SERVER apps (graduated), in plain text: why (context), what (decision), what follows (consequences) and when to revisit it (reexamen, at least 20 characters: a date or an event). These decisions join the app's runward mission in its proof dossier, after the four decisions of the kit, and runward checks them: a decision without a date, a status in its closed list or a reevaluation trigger is set aside. action='add' records one (status 'proposed' by default, or 'accepted'); action='list' (default) returns them; action='retire' marks one 'superseded' (never erased: the history of an app is not rewritten). At most 30 per app; title 120 characters, each section 2,000. Record a decision when you choose a data model, a link to another app, a security or privacy rule, or a trade-off the owner should remember. Then ask for a proof dossier (owner, in the cockpit) and read its verdict with dropyour_status. Owner only, with a connected account; refused for a simple page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dropId": "<dropId>"
    },
    "name": "dropyour_decision"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoFor retire: the decision id, e.g. 'd002'.
titreNoFor add: the decision in one line (120 characters at most).
actionNolist
dropIdYes
statutNoFor add: 'proposed' (default) or 'accepted'.
contexteNoFor add: why a decision was needed.
decisionNoFor add: what was decided.
reexamenNoFor add: when to revisit it, a date or an event (20 characters at least).
consequencesNoFor add: what follows, good and bad.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare openWorldHint=false, idempotentHint=false and destructiveHint=false; the description adds the real behavior: validation that silently sets aside decisions missing a date, status, or reevaluation trigger, a hard cap of 30 per app, character limits, and the fact that retire marks 'superseded' rather than erasing ('the history of an app is not rewritten') — consistent with destructiveHint=false. Authorization requirements and the refusal case are also disclosed.

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 every clause carries information, but the paragraph is dense and jargon-heavy ('graduated', 'runward mission', 'proof dossier', 'reexamen'), mixing English and French terms that are never defined. Some material (the four-decision kit placement, the cockpit aside) is incidental to invoking the tool correctly.

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 9-parameter, three-action mutation tool with no output schema, the definition covers validation, limits, auth, and follow-up well. Gaps are modest: the shape of the 'list' response is never described, and key domain concepts ('graduated', 'proof dossier') are referenced without definition.

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 78%, so the schema already carries most parameter meaning; the description adds value by explaining that 'reexamen' needs at least 20 characters and must be a date or an event, and by clarifying default status 'proposed' versus 'accepted'. Minor friction remains: it says title is 120 characters while the schema allows maxLength 400, which could confuse the agent.

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 opening sentence gives a specific verb and resource ('Write down a structural decision ... for one of the owner's SERVER apps') and immediately enumerates the three modes (add/list/retire) with their effects, so the agent knows exactly which operation it is looking at. The sibling boundary is also drawn: 'read its verdict with dropyour_status' separates recording from status-checking.

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 states concrete triggers ('when you choose a data model, a link to another app, a security or privacy rule, or a trade-off the owner should remember'), a scope exclusion ('refused for a simple page'), prerequisites ('Owner only, with a connected account'), and a named follow-up tool (dropyour_status). The per-action semantics (add records, list returns, retire marks superseded) complete the routing.

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.