Skip to main content
Glama
Sign In

GenFlick

by com.genflick
OverviewDiscussionsAdmin

Prepare higher spending limit

prepare_work_budget
Idempotent

Prepare a higher total credit limit for work that is already running, name the limit you read from get_work and the new total. This changes credits only: it adds no video, publishing, attempts or resources, never restarts stopped work, and does not itself raise anything. The creator reviews and approves the exact change in Genflick; then call raise_work_budget with the returned proposal.

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": {
      "work_id": "<work_id>",
      "expected_maximum_credits": "<expected_maximum_credits>",
      "maximum_credits": "<maximum_credits>",
      "request_key": "<request_key>"
    },
    "name": "prepare_work_budget"
  }
}

Input Schema

NameRequiredDescriptionDefault
work_idYesThe work whose limit would rise, from the proposal or get_work.
request_keyYes
maximum_creditsYesThe new total credit limit for the work, higher than the current one. It replaces the total; it is not an amount to add.
expected_maximum_creditsYesThe work's current total credit limit exactly as get_work returned it. A different current limit refuses the proposal.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations: it declares that only credits change, that no video, publishing, attempts or resources are added, that stopped work is never restarted, and that nothing is raised until the creator approves in Genflick. That is exactly the mutation-scope and human-gate context an agent needs before invoking a non-read-only 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?

Three sentences, front-loaded with the verb and resource, then the scope limits, then the approval-and-raise sequence. No filler and no repetition of the schema.

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?

Output schema exists, so return values need no explanation, and the description correctly points to 'the returned proposal' as the handoff to raise_work_budget. The only gap is the request_key/idempotency contract, which is left entirely to annotations and the bare schema property.

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 75% and the description reinforces the two easily-confused credit parameters by telling the agent to name the limit read from get_work (the expected/current value) alongside the new total. It adds little for work_id and says nothing about request_key, which is undocumented in both places.

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 object ('Prepare a higher total credit limit for work that is already running') and immediately scopes what it is not ('does not itself raise anything'), which cleanly separates it from the sibling raise_work_budget.

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 a concrete use context (work already running), the prerequisite data source (the limit read from get_work), and names the follow-up alternative raise_work_budget with the approval step in between. It stops short of stating explicit when-not conditions, such as behavior for stopped or finished work beyond the 'never restarts stopped work' note.

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

All GenFlick toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources