Skip to main content
Glama
Sign In
spoofzy

spoofzy

by spoofzy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Run a Spoofzy workflow

spoofzy_run_workflow

Run saved cloud workflows on local files, saved library originals, or text scripts, then save the results.

Instructions

Run a saved Spoofzy Cloud workflow on local files, on a saved original from the Spoofzy library (saved_original_id) or on a script (text, for voice workflows), then save the results. Uses the account's allowance: confirm with the user first. Needs a Cloud key with 'Run saved workflows' (plus 'Read workflows and history' to find the current version).

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": {
      "workflow_id": "<workflow_id>"
    },
    "name": "spoofzy_run_workflow"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNoOne file path; same as files: [path].
textNoScript for workflows that take text.
filesNoAbsolute paths of local images/videos, or folders (every supported file directly inside). Up to 20 files per call. Supported: JPG, PNG, WebP, HEIC, GIF, MP4, MOV, M4V and WebM.
versionNoWorkflow version (default: the current version).
downloadNoSave the results locally (default true). False returns temporary result links instead.
output_dirNoFolder for the results (created if needed). Default: a spoofzy-output folder next to each source file, or the configured SPOOFZY_OUTPUT_DIR.
request_idNoOnly to retry a call whose outcome was uncertain: pass the request_id it returned and Spoofzy returns the same runs instead of charging again. Leave empty for new runs.
workflow_idYesA workflow id (wa_…).
wait_secondsNoSeconds to wait for processing before returning (default from SPOOFZY_WAIT_SECONDS, normally 50). Unfinished runs keep processing and are saved when ready while this server runs; check them with spoofzy_get_run.
saved_original_idNoId from spoofzy_list_saved_originals.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only flag non-read-only, open-world, non-idempotent, non-destructive; the description adds genuinely new behavior — the call draws down the account's allowance and requires user confirmation, and it requires specific key permissions. It also discloses that results are saved rather than merely returned. It omits failure/partial-run behavior beyond the schema's note about spoofzy_get_run.

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?

Two sentences, front-loaded with what the tool does and followed by cost and credential constraints — no filler. The dense parentheticals are functional, though the second sentence packs three separate constraints into one long clause.

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 10-parameter, open-world, costly mutation with no output schema, the description covers input modes, credit cost, confirmation, permissions, and result saving. What an agent still lacks is what a call returns (run ids/statuses) and what happens on partial or failed processing, though the schema points to spoofzy_get_run.

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%, so every parameter is already documented, setting the baseline at 3. The description adds only marginal semantics beyond that, clarifying that 'text' applies to voice workflows and tying 'version' to the need for read-history permission; the remaining parameters get no extra meaning from the description.

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?

States a specific verb and resource ('Run a saved Spoofzy Cloud workflow') and enumerates the three input modes: local files, a saved original (saved_original_id), or script text for voice workflows. It is clear on its own, but it never distinguishes itself from sibling spoofzy_spoof, which an agent could plausibly confuse it with.

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 concrete preconditions: confirm with the user first because it consumes the account's allowance, and it needs a Cloud key with 'Run saved workflows' plus 'Read workflows and history' to resolve the current version. It does not name an alternative tool or state when NOT to use this one, so it stops short of full routing guidance.

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