fuast

Run a handler of an app

call_app

Destructive

Runs one query, mutation or action of a deployed app and returns its result and the log lines it wrote, so you can test what you deployed. It runs as the connected person (as: "me", the default), never as anyone else; as: "guest" runs it as a guest visitor and only works on public apps. On a preview deployed without an account every call runs as one guest. Mutations and actions change real data. Only for apps the person owns or administers.

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": {
      "kind": "<kind>",
      "name": "<name>"
    },
    "name": "call_app"
  }
}

Input Schema

Name	Required	Description
`as`	No	Who the handler sees in ctx.auth. Default "me".
`app`	No	The app's slug: the first label of its address (my-app for https://my-app.fuast.com). list_apps shows the slugs you can use.
`args`	No	Arguments: an array of positional values, or one object for handlers that take an object (tool handlers). Default: no arguments.
`kind`	Yes	Which kind of handler name is.
`name`	Yes	Handler name as declared in server/index.ts.
`edit_token`	No	The edit_token deploy_app returned when it deployed a preview without an account. It is a secret: keep it in this conversation only.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`logs`	No
`name`	Yes
`slug`	No
`ran_as`	Yes
`result`	No
`truncated`	No
`duration_ms`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true; the description adds real substance on top by warning 'Mutations and actions change real data' and explaining identity semantics ('runs as the connected person... never as anyone else', guest mode only on public apps, preview-without-account forced to guest). It does not cover error behavior or whether partial effects persist on failure, which keeps it at 4 rather than 5.

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?

Three dense sentences, front-loaded with what the tool does and its return value, then identity rules, then the mutation warning. Every sentence carries information, though the guest/preview clauses stack up slightly and could be tightened.

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?

With an output schema present, return values need no explanation; all six parameters are schema-documented and the tricky one is amplified in prose. The remaining gap is failure behavior for a destructive, non-idempotent call — an agent knows mutations hit real data but not what happens on error or whether retries are safe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description meaningfully deepens the 'as' parameter beyond the schema's terse 'Who the handler sees in ctx.auth': it fixes the default, explains what 'guest' actually does, and describes the forced-guest case for account-less previews. That is real semantic value the schema cannot convey.

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 ('Runs one query, mutation or action of a deployed app') and names the outcome and return payload ('its result and the log lines it wrote'). It frames the intent as testing a deployment, which is concrete. It never names a sibling tool to contrast with, so differentiation is left to the schema's mention of list_apps.

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 clear operating context: testing what you deployed, ownership restriction ('Only for apps the person owns or administers'), and the guest-mode constraint ('only works on public apps'). It does not explicitly say when to prefer inspect_app, get_logs, or check_app instead, but the usage condition is unambiguous.

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

All fuast 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.

Resources

Need Help?