Free experimental GPU tools: text generation, images and audio transcription. Shared quotas; no SLA.
Scored across 9 tools
The three submit_* tools are cleanly separated by modality (chat, image, audio/compute), but the read side has two parallel look-alike pairs: get_compute_job vs get_studio_job and get_compute_status vs get_service_status. Descriptions do distinguish them, yet 'compute' vs 'studio' is an opaque split that invites misselection when an agent just wants to poll a job or check availability.
All nine tools follow snake_case verb_noun (create_, get_, submit_ + object), which is predictable. The only blemish is the inconsistent domain vocabulary where 'compute' means audio transcription while 'studio' covers chat and images, so the middle token doesn't consistently map to a resource family.
Nine tools is well-scoped for a job-queue service: one access tool, three submission tools, three retrieval tools and two status probes, with nothing obviously redundant. Each tool maps to a step in the submit-poll-retrieve lifecycle.
The core lifecycle is covered end to end per modality: acquire trial token, submit, poll job, and fetch the rendered image for image work, plus availability checks. Gaps are secondary — there is no cancel/abandon job, no list-my-jobs tool, and no token revoke, so an agent cannot enumerate or clean up outstanding work.
Create a private 24-hour trial token automatically. No ChatGPT account, payment or manual setup. Audio: 3 jobs per session. Chat/images: 24 total submissions per rolling 24 hours, 10 per session/reported client, one active task per session, shared queue of 3. Global access issuance caps apply. Retain the token for upload and result retrieval. Reuse the session; never create new sessions to bypass quotas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and idempotentHint=false; the description goes well beyond that with concrete quotas (3 audio jobs, 24 submissions per rolling 24h, 10 per session), concurrency behavior (one active task per session, shared queue of 3), global issuance caps, and a 24-hour token lifetime. It also warns against session recreation to evade quotas, which is exactly the kind of behavioral trait an annotation cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The action and access conditions are front-loaded in the first two sentences, with quota details following. The quota clause is dense and telegraphic ('10 per session/reported client'), but every sentence carries operational information; nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description must carry the full load, and it covers lifetime, quotas, concurrency, and token retention. The one gap is that it never says the token is returned in the response body or under what field, leaving the agent to inspect the result to find it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description does add relevant context about what the caller must do with the returned token, but no parameter-level detail is needed or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource ('Create a private 24-hour trial token') plus a key qualifier ('automatically'), so the agent knows exactly what action is taken and for how long. It doesn't explicitly name a sibling alternative, but the 'no ChatGPT account, payment or manual setup' framing makes its role as the pre-auth entry point obvious against the submit_*/get_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description supplies clear context for when this applies (no account/payment/manual setup) and imperative follow-through ('Retain the token for upload and result retrieval', 'Reuse the session; never create new sessions to bypass quotas'). It stops short of explicitly stating 'call this before submit_chat_job when you have no token', so the linkage to siblings is inferred rather than named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a previously submitted job by job_id. Returns status, transcript, runtime and reference quality when complete. For queued or running jobs, wait poll_after_seconds before checking again. Failed or expired jobs are not successful results.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Exact job_id returned by submit_compute_job. | |
| access_token | No | Temporary trial token, unless Bearer authentication is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that: what fields come back (status, transcript, runtime, reference quality) and how to handle non-terminal states via poll_after_seconds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and result fields, then polling guidance. No filler, though the final sentence ('Failed or expired jobs are not successful results') is slightly redundant with the status guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of naming the returned fields and explaining polling behavior, which is what an agent needs. It could say a bit more about what 'reference quality' looks like, but nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both job_id and access_token are already documented, including the pattern and the auth fallback. The description only echoes 'by job_id' without adding format or usage nuance, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read a previously submitted job by job_id') and clarifies the result semantics. It implicitly distinguishes itself from submit_compute_job via 'previously submitted', but never names the sibling get_compute_status, so an agent must infer which read tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operational guidance: wait poll_after_seconds for queued/running jobs, and treat failed/expired jobs as not-successful results. It stops short of explicitly contrasting with get_compute_status, so routing between the two read tools is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the GPU provider can accept audio transcription work. Returns availability, permitted task types, and limits. Does not start a job.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent read with no side effects, so the description's job is to add what they don't say. It does: it names the returned fields (availability, permitted task types, limits) and explicitly states no job is started, which prevents a costly misread. Missing only auth or rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, purpose first, the returned data second, and the critical non-behavior last. No filler and nothing repeated from the annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns and does so in one clause. The remaining gap is sibling disambiguation between this and the similarly named get_compute_job/get_service_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-arg tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check') and resource ('GPU provider availability') and enumerates what the result conveys. The clause 'Does not start a job' separates it from the submit_* siblings, though it does not explicitly distinguish it from get_compute_job or get_service_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The negative constraint 'Does not start a job' implies this is a pre-flight check used before submitting work, but the description never says when to call it or names the alternatives it should be chosen over. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public live availability, model catalog, free-trial limits and polling guidance. No token required. Check before submitting; an offline GPU cannot execute work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely non-structured context: 'No token required' (auth requirement) and 'live' (freshness of the data), plus a consequence statement about offline GPUs. It doesn't mention rate limits or caching, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the return contents before the auth note and the call-to-action. Every sentence earns its place, though the opening noun list reads telegraphically rather than as a complete statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema and full annotation coverage, the description carries the remaining burden of saying what comes back and why to call it — both of which it does. The absence of an output schema means the enumerated content categories are the only signal about return shape, and they are sufficient for an agent to decide to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is trivially empty, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-arg tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates the concrete payload: live availability, model catalog, free-trial limits and polling guidance, which tells an agent exactly what this zero-arg call returns. It stops short of an explicit verb ('get'/'check'), opening with a noun phrase, but the resource is unambiguous and distinct from siblings like get_compute_status (per-job) or submit_*_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Check before submitting; an offline GPU cannot execute work' gives an explicit precondition that routes the agent to this tool ahead of the submit_* siblings. There is no explicit when-not or named alternative for cases where the agent already knows availability, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the completed image as an MCP image content block. Requires the same token/identity that submitted the job. Images expire after 24 hours from submission; download before expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| access_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: an identity/ownership requirement and a hard 24-hour retention window after which the resource is unrecoverable. It also discloses the return shape (an image content block), which annotations do not. It omits what happens on expired or not-yet-complete jobs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what is returned, followed by the auth prerequisite and the expiry constraint. No sentence is redundant with the annotations or the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly spends a line specifying the return type, and no annotations substitute for the retention and auth facts. The only gap for a 2-parameter retrieval tool is error behavior (expired job, wrong token, job still running).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by explaining the access_token must match the submitting identity, but job_id is never characterized beyond its regex pattern (where it comes from, whether a job or studio job id is expected) and the distinction between job_id and the token is left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it returns the completed image as an MCP image content block, which clearly separates it from metadata-oriented siblings like get_studio_job and get_compute_status. It never names a sibling explicitly, so the differentiation is inferable rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the two conditions an agent actually needs: the same token/identity that submitted the job must be used, and the image must be retrieved within 24 hours. It does not say whether to poll get_studio_job for completion first or what to do if the job is unfinished, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read your own chat/image job. Includes partial text while running, final text or image availability, GPU runtime and server timings. Wait poll_after_seconds between checks; stop on succeeded, failed or expired. Does not create or retry work.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| access_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds real value on top: partial results are returned while running, what fields come back (GPU runtime, server timings), and the terminal-state set. The only gap is it doesn't explain error behavior for an invalid or foreign job_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the resource, then return contents, then polling rules. Every sentence carries information; the only minor friction is referencing poll_after_seconds, a response field that appears nowhere in the schema or description context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does a good job sketching return contents and terminal states, and annotations cover the safety profile. It falls short only on parameter-level essentials (job_id shape, access_token) that an agent must get right to call the tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and neither of the two parameters is described: neither the job_id format (the schema carries a strict ^studio_[a-f0-9]{32}$ pattern that an agent could easily violate) nor the purpose of access_token ("your own" hints at ownership scoping but doesn't say it). The description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Read your own chat/image job") and enumerates what the read yields (partial text, final text or image availability, GPU runtime, server timings). It implicitly separates itself from submit_* siblings and from get_studio_image by framing this as job-status reading, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operational guidance: poll with poll_after_seconds between checks and stop on succeeded/failed/expired, which is exactly the loop an agent needs. It also bounds scope with "Does not create or retry work," routing creation/retry elsewhere, though it does not name the specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a free text task: draft, summarize, extract, translate text, reason or assist with code. No code is executed. Provide user/assistant messages, explicit consent for nonconfidential permitted content, and a stable idempotency key. Returns immediately with a job ID. Poll get_studio_job. Uses the configured local model, no external AI fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| consent | Yes | Confirm permission to process this nonconfidential content. | |
| messages | Yes | At most 12,000 characters in total. End with a user message. Include previous messages for follow-up context. | |
| access_token | No | Private token from create_trial_access; optional with Bearer authentication. | |
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover idempotency and non-destructiveness, but the description adds substantial context: asynchronous return with a job ID, the need to poll get_studio_job, local-model-only operation with no external AI fallback, and the consent requirement for nonconfidential content. This goes well beyond what the annotations state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and task types, then proceeds through required inputs, return behavior, and polling instructions. Every sentence carries actionable information with no redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an asynchronous job submission tool with no output schema, the description covers what the agent must know: the immediate return is a job ID, subsequent polling uses get_studio_job, and the local-model/no-fallback constraint is disclosed. Combined with the schema details for messages and limits, nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the schema already documents most parameters. The description adds useful semantics beyond the schema: consent is specifically for 'nonconfidential permitted content' and the idempotency key should be 'stable' for retry safety. The access_token parameter is not mentioned in the description, leaving one gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('queue a free text task') and enumerates the task types (draft, summarize, extract, translate, reason, code assistance). It distinguishes itself from the compute/image siblings through 'free text' and 'No code is executed', making the resource and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The task list gives clear context for when this tool applies, and it explicitly routes the agent to get_studio_job for polling. The implicit exclusion of actual code execution ('No code is executed') helps, but it does not name submit_compute_job or submit_image_job as alternatives for those cases, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Transcription only, or transcription with the reference quality gate. | |
| asset_id | No | Owned upload ID returned by POST /v1/beta/upload. Required for public beta buyers. | |
| access_token | No | Temporary token returned by create_trial_access. Optional when Bearer authentication is configured. | |
| idempotency_key | Yes | Unique request key. Keep it unchanged on retries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: no payment is charged, no accuracy guarantee for uploaded files, a job_id is returned for polling, and authentication can come from a trial access token. The one opaque sentence about 'Owner legacy calls' queueing a 'fixed synthetic benchmark' is unexplained and slightly muddies otherwise clear behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded with the required-input rule and the two kinds before the return/polling and idempotency details. Nearly every sentence carries information, but the unexplained 'Owner legacy calls ... synthetic benchmark' line costs a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly covers what comes back (job_id, transcript) and how to continue (poll get_compute_job), plus billing and auth expectations. It leaves the legacy benchmark path and any failure/partial-result behavior undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3; the description earns above that by giving conditional meaning the schema only states flatly ('Beta users must supply their uploaded asset_id') and by explaining kind in terms of outcome (transcript vs transcript plus WER gate). idempotency_key semantics are restated and elaborated usefully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action (submit a job that produces a transcript) and disambiguates its two modes: compute_job returns a transcript while delegated_task adds a WER gate. It is clearly an audio-transcription submitter rather than a chat/image one, though the sibling relationship is carried by the title rather than the prose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real selection guidance: beta users must supply asset_id, compute_job vs delegated_task is chosen by whether a quality gate is needed, and results are retrieved via get_compute_job. It also states retry policy (same idempotency_key on retries, new key only for a new job). No explicit when-not-to-use or comparison to submit_chat_job/submit_image_job, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a free text-to-image task from a complete scene description. Each task is independent, not an edit of a previous image. Returns a job ID; poll get_studio_job then get_studio_image for the PNG. Configured model and size appear in service status/results. No external AI fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Complete image description. English prompts are recommended. | |
| consent | Yes | Confirm permission to process this nonconfidential content. | |
| access_token | No | Private token from create_trial_access; optional with Bearer authentication. | |
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent, non-destructive, closed-world semantics, so the bar is lower; the description still adds real value by disclosing the async job-ID return, the polling path to the PNG, that model/size are surfaced in service status, and that there is no external AI fallback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences, front-loaded with the action and immediately followed by the independence constraint and the polling path. The model-configuration and no-fallback notes are slightly tangential but earn a few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains the return (a job ID) and how to retrieve the result, plus where model/size metadata shows up. Enough for an agent to call and follow through; only the idempotency-key retry contract is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and prompt/consent/access_token are documented in the schema, so baseline is 3. The description adds only the 'complete scene description' framing for prompt and says nothing about idempotency_key or how the free-tier consent requirement interacts with retries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Queue a free text-to-image task') and clarifies scope with 'Each task is independent, not an edit of a previous image', which cleanly separates it from the sibling submit_chat_job and submit_compute_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear use context (full scene description, independent generation, not an edit) and an explicit follow-up workflow via get_studio_job then get_studio_image. It does not explicitly contrast with submit_chat_job, so the when-to-use-this-vs-that guidance is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_trial_accessget_compute_jobget_compute_statusget_service_statusget_studio_imageget_studio_jobsubmit_chat_jobsubmit_compute_jobsubmit_image_job15 tools: LLM chat, summaries, translation, embeddings, speech, images. From $0.002.
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Generate AI images, video, and audio with many frontier models, private by default.
Add one secure layer between your agents and this server.
