AnimatedWebs

Manage my AnimatedWebs template requests

manage_request

DestructiveIdempotent

Lists, checks or cancels the signed-in account's own template requests (sent with request_template or the contact form's template-request topic). Use it to follow up on a request instead of sending it again; use request_template to send a new one. action list (default) returns recent requests newest first; action status returns one request by id; action cancel withdraws one request by id, which only works while it is still received (not yet reviewed) and marks it cancelled so the team skips it. Each request has id, createdAt, the first 200 characters and status (received, reviewed or cancelled). Only the account's own requests are visible or cancellable: another account's id answers as not found. list and status change nothing; cancel cannot be undone (send a new request instead). Examples: {"action":"list","limit":5}, {"action":"cancel","id":42}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "manage_request"
  }
}

Input Schema

Name	Required	Description	Default
`id`	No	Request id as returned by request_template or list. Required for status and cancel.
`limit`	No	For list: how many recent requests, 1 to 50 (default 10).
`action`	No	list (default): recent requests. status: one request by id. cancel: withdraw one received request by id.	list

Output Schema

Name	Required	Description	Default
`action`	Yes
`requests`	Yes	For status and cancel: the one request, after the change

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true, openWorldHint=false), the description discloses the precondition for cancellation, that the request is marked cancelled so the team skips it, that cancel cannot be undone, and that list/status change nothing. It also explains the ownership boundary — another account's id resolves as not found — which annotations cannot convey. What it does not add is pagination or ordering guarantees beyond 'newest first' for list.

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

Conciseness4/5

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

It is front-loaded with purpose, then the verb-to-action mapping, then constraints, then concrete call examples — a sensible order with no filler sentences. It is dense rather than bloated, though a single paragraph carrying three actions plus examples makes the cancel precondition easy to skim past; light structural separation would help.

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?

For a three-action tool with an output schema, this covers everything an agent needs: action selection, required id, limit bounds, ownership scoping, irreversibility, and even sample payloads. Return-value details are already handled by the output schema, and the description does not redundantly over-specify them.

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 100%, so the baseline is 3, but the description adds real meaning: which action requires id, what id yields when it is not yours ('not found'), that limit bounds 'recent requests' returned newest first, and that each request carries id, createdAt, first 200 characters and status. That is more than the enum strings alone convey.

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 names three specific verbs (lists, checks, cancels) against a precisely scoped resource (the signed-in account's own template requests) and pins down how such requests originate. It explicitly contrasts itself with the sibling request_template, so an agent can route correctly without inspecting either 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?

It states when to use this tool ('to follow up on a request instead of sending it again') and names the alternative for the opposite case ('use request_template to send a new one'). It further refines selection between its own actions: list for recent requests, status for one by id, cancel only while a request is still 'received' and not yet 'reviewed'.

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

All AnimatedWebs tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.