floot

Call App Function

call_app_function

Destructive

Call one function of this project's own backend, the way its own code would: a function the project exports from helpers/flootAppExports.tsx, run in its published app, returning that function's JSON result. list_files shows the project's exported functions with their signatures; the function name and its input come from there. Use it to test an export after publishing it, or to do something for the user through the app's own logic instead of raw SQL. The function runs for real (a function that writes, sends or charges does so), so call one that changes anything only when the user asked for that change. Only functions in the last publish; needs edit access to the project. Up to 25 seconds; no answer in time does not mean it did not run. Details: get_guides("app-calls").

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": {
      "projectId": "<projectId>",
      "function": "<function>"
    },
    "name": "call_app_function"
  }
}

Input Schema

Name	Required	Description
`input`	No	The function's argument as JSON, of the type its signature in list_files shows. Omit for a function that takes none.
`function`	Yes	The name of a function this project exports from helpers/flootAppExports.tsx, as list_files shows it.
`projectId`	Yes
`timeout_seconds`	No	How long to wait for the function, in seconds.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructive and open-world, and the description goes further by explaining what destruction means concretely ('a function that writes, sends or charges does so'), that it only reaches the last publish, that edit access is required, and that a 25-second timeout does not imply the function failed to run. That timeout caveat is behavior an agent could not infer from the annotations or schema.

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 the core action and then proceeds through discovery, usage, hazards, prerequisites, and timeouts, with no filler sentences. It is dense and reference-laden (file path, guide name), but each clause carries operational information.

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 tool with no output schema, the description still tells the agent what comes back ('that function's JSON result') and how to find valid inputs, plus the timeout and prerequisite conditions. Nothing an agent needs to invoke it correctly is missing.

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 adds real meaning on top: the function name and its input are derived from list_files signatures, and 'input' is the JSON argument typed per that signature, omitted when the function takes none. projectId remains undocumented in both schema and description, which is the only gap.

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?

Names a specific verb and resource ('call one function of this project's own backend'), pins the exact source ('exported from helpers/flootAppExports.tsx'), and states the execution context ('run in its published app, returning that function's JSON result'). This clearly separates it from siblings like execute_sql, run_code_in_vm, or run_tests.

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?

Gives explicit when-to-use ('test an export after publishing it, or to do something for the user through the app's own logic instead of raw SQL'), a when-not constraint ('call one that changes anything only when the user asked for that change'), and prerequisites ('only functions in the last publish; needs edit access'). It also routes to list_files for discovering names and signatures.

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

All floot tools Inspect

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

Need Help?