Skip to main content
Glama
Sign In
AI GIF Maker MCP server

AI GIF Maker MCP server

by hanshs474
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Check a GIF that is still running

check_gif

Fetches the GIF URL for a queued generation task using its task ID, so you can confirm when the animation is ready.

Instructions

Look up a GIF by the task id generate_gif returned when it was still running, and return its URL once it is ready. Free to 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": {
      "task_id": "<task_id>"
    },
    "name": "check_gif"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYesThe task id from generate_gif.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the behavior burden. It discloses the key traits: a lookup keyed by a prior task id, a readiness-dependent result, and 'Free to call' (no credit cost, implicitly contrasting with check_credits). It does not say what happens when the task is not yet done, has failed, or the id is invalid.

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?

One front-loaded sentence covering input source, action, and result, followed by a short cost note. Nothing is wasted and there is no filler.

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 one-parameter polling tool with no output schema and no annotations, the description covers the essential loop (generate_gif then check_gif) and the return value well. Gaps around pending/failed/expired states and polling cadence keep it short of full completeness.

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 single required parameter is already documented as 'The task id from generate_gif.' The description reinforces the provenance of the value but adds no new syntax or format detail, so baseline 3 is appropriate.

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 resource (look up a GIF), names the exact input source (task id from generate_gif), and says what it returns (the URL once ready). An agent can distinguish it from generate_gif and check_credits 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 Guidelines4/5

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

Clearly frames the polling scenario: use this after generate_gif while the task is still running. It implies repeated calling until the GIF is ready, but does not state what to do on failure, expiry, or an unknown task id, nor a polling interval recommendation.

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

Deploy Server

Other Tools