Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

Test a function

test_function

Run a function's current code once in a temporary sandbox with request_body as the request, and return its status code, time and response. A form on the site sends its fields under "data", so to test as a page would, send { "data": { "": "" } }. The run is real: the code has the function's env vars and data access, so anything it writes or calls happens.

Input Schema

NameRequiredDescriptionDefault
site_idYesThe site, from list_sites
functionYesThe function's name (slug), display name or id, from list_functions
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
request_bodyNoThe JSON request body to send (default {})

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Adds information annotations cannot carry: despite being a 'sandbox', the run is real — the code has the function's env vars and data access, so writes and outbound calls actually happen. That is exactly the side-effect warning an agent needs before invoking an openWorld, non-idempotent tool, and it does not contradict destructiveHint=false.

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?

Three sentences, each doing distinct work: what it does, how to shape the request, and the side-effect warning. The warning is placed last as the highest-stakes point, 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?

No output schema exists, yet the description names what comes back (status code, time, response), covers the request-body shape, and warns about real side effects. Only gap is the absence of any note about permissions or how long the temporary sandbox persists.

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 baseline is 3, but the description genuinely adds meaning for request_body by showing that page form fields must be wrapped as { "data": { "<field>": "<value>" } }, plus a concrete example. site_id and function are left to the schema, and user_goal is unaddressed, so not a 5.

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 the function's *current* code once in a temporary sandbox, and names the return values (status code, time, response). This distinguishes it functionally from deploy_function and get_function_details, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Provides concrete guidance on how to shape request_body to simulate a page submission (nesting fields under "data"), which is usage-oriented. But it never states when to choose this over deploy_function or get_function_details, and gives no exclusions or prerequisites such as required permissions.

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

All Mondovo toolsInspect
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