Skip to main content
Glama
Sign In

AgentCompute

by io.github.Ockram4444
OverviewDiscussionsAdmin

Submit an audio transcription job

submit_compute_job
Idempotent

Beta users must supply their uploaded asset_id and kind compute_job. No accuracy guarantee is made for uploaded files. Owner legacy calls can queue the fixed synthetic benchmark. compute_job returns a transcript; delegated_task additionally requires word error rate at most 10% against the known reference. Returns a job_id to poll with get_compute_job. No payment is charged. Reuse the same idempotency_key for retries, and use a new key only for a new job.

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>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "submit_compute_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesTranscription only, or transcription with the reference quality gate.
asset_idNoOwned upload ID returned by POST /v1/beta/upload. Required for public beta buyers.
access_tokenNoAccount credential created in My account. Optional when Bearer authentication is configured.
idempotency_keyYesUnique request key. Keep it unchanged on retries.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / access_token / description
      Previous value: -"Temporary token returned by create_trial_access. Optional when Bearer authentication is configured."New value: +"Account credential created in My account. Optional when Bearer authentication is configured."
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations (which already cover idempotency and non-destructiveness), it discloses concrete behavior: no accuracy guarantee for uploaded files, no payment charged, a 10% WER requirement for delegated_task, and async job_id semantics. The retry rule ('reuse the same idempotency_key... new key only for a new job') adds operational context the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short with little filler, but it is not front-loaded: it opens with a beta-user constraint rather than the action, and phrasing like 'Owner legacy calls can queue the fixed synthetic benchmark' is cryptic and reads as compressed notes. Several sentences pack multiple clauses, hurting parseability.

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 mutating, async job-submission tool with no output schema, it covers what an agent needs: inputs required by user type, the returned job_id and how to poll, cost (none), quality caveats, and idempotency/retry behavior. Error cases and polling cadence are the only notable omissions.

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 the baseline is 3, but the description adds genuine meaning: asset_id must come from an uploaded asset and applies to beta buyers, and kind's two enum values are tied to distinct obligations (plain transcript vs. reference quality gate). This goes beyond restating the schema descriptions.

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?

The description names a concrete action (submit a transcription job), the two job kinds, and what is produced ('returns a transcript', 'Returns a job_id'). Sibling differentiation is only implicit (the other submit_* tools are for agent/catalog/chat/image jobs), but the compute/transcription framing is clear enough that an agent can distinguish it.

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?

It gives real routing guidance: beta users must use kind=compute_job with an uploaded asset_id, legacy owner calls target the fixed synthetic benchmark, and delegated_task carries the WER<=10% gate. It also names the follow-up tool (get_compute_job) for polling, but it never states when to prefer a sibling submit_* tool or when not to call this one.

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

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