Skip to main content
Glama

Glasser

by ai.glasser
OverviewDiscussionsAdmin

Run endpoint

run
DestructiveIdempotent

Execute one endpoint and charge the workspace per its published price. Build input against the inspected input_schema. Generate a UUID for idempotency_key and reuse the SAME key to retry — it never charges twice; the result carries replayed:true on a replay. A provider 404/500 is a COMPLETED run carrying that outcome in provider_response, not an error. A QUEUED/RUNNING result means an async endpoint is still working — poll runs_get. The user's own keys and integrations outrank Glasser; never run speculatively, in loops or in bulk without naming the price and getting the user's go-ahead. The result's run_url opens the run's records in the workspace console, exactly as the provider returned them (members only); when your answer relies on the run, cite run_url as its source — the run id alone opens nothing. Docs: https://glasser.ai/docs/api-reference/runs/create

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputNo
task_idNo
endpointYes
providerYes
idempotency_keyYes
endpoint_versionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / task_id
      Added value: +{
+  "anyOf": [
+    {
+      "description": "The task this run belongs to, from a catalog search response. Grouping only: it never affects routing, price or idempotency.",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructive/idempotent/openWorld, and the description adds substantial context beyond them: billing per published price, idempotency_key reuse semantics with replayed:true, the counterintuitive rule that a provider 404/500 is a COMPLETED run carried in provider_response, and run_url being members-only.

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?

Dense but front-loaded: capability and charge first, then idempotency, then error/async semantics, then safety guardrails, then run_url citation. Every sentence carries a distinct operational rule; nothing is filler.

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?

There is no output schema, so the description compensates by describing return fields (replayed, provider_response, run_url) and the async polling path. For a destructive, billable, open-world call it covers safety, cost, idempotency and follow-up actions completely.

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 description coverage is reported at 0% (only task_id and endpoint_version carry inline descriptions), so the description must carry weight. It explains idempotency_key generation/reuse and points input construction at the inspected input_schema, but leaves provider and endpoint format unstated beyond their patterns.

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?

Opens with a specific verb+resource+consequence: 'Execute one endpoint and charge the workspace per its published price.' It also implicitly differentiates from siblings by routing async polling to runs_get, so an agent can tell it apart without reading schemas.

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?

Explicit when-to-use and when-not: poll runs_get for QUEUED/RUNNING results, and 'never run speculatively, in loops or in bulk without naming the price and getting the user's go-ahead.' It also defers to the user's own keys/integrations over Glasser, giving a clear precedence rule.

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

All Glasser 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