Skip to main content
Glama

Approve or reject the Flow agent's spend request (may spend credits)

flow_approve

Approves or rejects pending credit-cost requests, spending credits only when the quoted amount is within your max limit. Returns the agent's reply and any started media.

Instructions

Answers the agent's pending 'costing N credits?' request. decision 'approve' SPENDS the quoted credits, but only when N <= max_credits; otherwise it rejects and nothing is spent. Never chooses 'Always approve'. Returns the agent's reply and the media it started (videos then render for 1-5 min: fetch them with flow_wait using since/media).

Input Schema

NameRequiredDescriptionDefault
decisionYes
project_idYes
max_creditsYesHighest quoted cost to approve; ask the user
include_thinkingNoAlso return the agent's reasoning ('Show thinking')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does: it discloses that approve SPENDS credits, that rejection spends nothing, the max_credits gate, the 'Never choose Always approve' constraint, and that results include media that renders for 1-5 minutes. This is exactly the behavioral context an agent needs for a spend-affecting tool.

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?

Front-loaded with the triggering condition, then the decision semantics, then the follow-up fetch step. Four dense sentences, no waste or redundancy.

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, and the description explains what is returned (agent's reply and started media) plus the render timing and the sibling tool to fetch results with. For a spend-impacting mutation tool, nothing needed to invoke it correctly is missing.

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 50%, and the description compensates well for decision and max_credits by explaining their interaction (approve spends only when N <= max_credits). It does not describe include_thinking, though the schema itself documents it, so this falls just short of full.

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 (answer/approve) and resource (the agent's pending 'costing N credits?' request), and makes the approve/reject semantics explicit. An agent can distinguish this from flow_wait, flow_credits and other siblings 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 Guidelines5/5

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

Explicit when-to-use: answer the pending cost request. Explicit when-not: approve only if N <= max_credits, otherwise reject and nothing is spent. Names the follow-up alternative (flow_wait with since/media) and rules out 'Always approve'.

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