Skip to main content
Glama

Answer a decision

answer_decision
Destructive

Answers one waiting decision with one of its options (see list_decisions). Options that need words (notes for a change, a link) take them in text. This is the owner's answer, given in their name: posting, publishing, sending and spending follow the option, and the answer teaches Marsell like the owner's own. Like the owner's own press in Marsell, what it approves is never held by an agent's switch: a reply or an email goes at once, a post on its day, and only Marsell's work paused for the whole business makes it wait until that is switched back on. On a card that asks before big work, make spends its price, and each other way the card offers (another level, or another kind, such as a Short in motion graphics or as AI video) spends the price on its own option; the option to go ahead without asking spends make's price and sets the owner's own budget for that kind of work. A card is answered once: one already answered, or being answered at that moment, is refused with who answered it. A homework card is refused here, and so is the card that asks who Marsell may talk to for them and whether it goes ahead on its own: only the owner answers those, in Marsell. Work the owner handed you from Copy for your agent (a reply to post in its thread, a message to send, a reply to paste) is reported back here, one call for each one you did: the option that says it is done (posted, sent or done, named on each in the brief) with the public link of what you posted in text (leave text out for an email or a private message); skipping one stays the owner's call.

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": {
      "decision_id": "<decision_id>",
      "option": "<option>"
    },
    "name": "answer_decision"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNoWords for an option that asks for them (its needs_text): the owner's notes for a change, or the public link of what you posted.
optionYesThe option's key, exactly as list_decisions gives it (approve, keep, skip, later and the rest differ by card).
board_idsNoFor a storyboard round's "pick": the storyboards to make, from the decision's board_ids in list_decisions. Each one made spends its quote.
decision_idYesThe decision's id, from list_decisions, card_read or get_overview.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Beyond the destructive/openWorld annotations it adds genuinely useful behavior: effects fire immediately or on schedule depending on the option, spend options burn a price, and a card is answered once so a re-answer is refused with the responder's identity. That is real added context, but the explanation is delivered in dense metaphorical prose ('never held by an agent's switch', 'spends make's price') that is harder to act on than a plain statement of consequences, and the success return is not described despite there being no output schema.

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

Conciseness2/5

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

The first sentence is front-loaded and precise, but the body is a single sprawling passage of ornate, repetitive phrasing ('like the owner's own', 'each other way the card offers (another level, or another kind, such as a Short in motion graphics or as AI video)') where a short list of refusal cases and effect rules would carry the same content. Several sentences would need to be read twice to extract an actionable rule.

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 destructive, open-world mutation with no output schema, the description covers the things an agent most needs: prerequisites, refusal conditions, spend consequences, idempotency, and the multi-item reporting protocol. The main gap is that it never states what a successful call returns or confirms.

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 coverage is 100% and the schema already explains text, option, board_ids and decision_id well. The description mostly restates that (text for options needing words, the public link for posts, omit text for email/private message), adding only marginal nuance about spend-on-own-option for board picks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Answers one waiting decision with one of its options') and points at list_decisions for the option set, which separates it from the query-side siblings. What it does not do is distinguish itself from adjacent answer-style siblings such as answer_question, ad_answer or homework_done, so the differentiation is only partial.

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?

It gives real routing rules: consult list_decisions first, one call per handed-off work item (reply, message, paste), and explicit exclusions — homework cards and the consent/audience card are refused here and must be answered by the owner in Marsell. It stops short of saying which sibling to use for those refused cases (homework_done exists), leaving the alternative implicit.

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.