Script in, finished 1080p narrated video out. Pay per call in USDC via x402.
Fetch the finished video path and size once the job is done. Free.
job_id: id returned by submit_video_job
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details itself. However, it only states 'Free' and the fetch action. It does not explain what happens if the job is not finished, whether it polls, or what error responses may occur. This leaves the agent without essential behavioral expectations.
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 minimal and front-loaded with the main purpose. The second part directly explains the single parameter. Every sentence provides useful information, and there is no redundant content.
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 a simple fetch tool with one parameter, the description covers the key aspects: what is fetched, when (once job done), and where to get the job_id. It does not describe the output format, but no output schema exists, so this is a minor gap. Overall, it is sufficiently complete for its complexity.
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 only lists job_id as a required string with title 'Job Id'. The description adds meaning by stating 'id returned by submit_video_job', giving the agent a direct source for the parameter. This compensates for the complete lack of schema descriptions (0% coverage).
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 clear action: 'Fetch the finished video path and size once the job is done.' This specifies the exact resource (finished video path and size) and the condition (once job is done), distinguishing it from sibling tools like get_job or list_jobs.
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 phrase 'once the job is done' provides clear timing for use, indicating that this tool should be used after job completion. It does not explicitly name alternatives or exclusions, but the context implies it is for retrieving results, not checking status (which likely belongs to get_job).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a video job until it is done. Free. Use after submit_video_job returns a job_id.
job_id: id returned by submit_video_job, e.g. a1b2c3d4e5f6
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It discloses that it polls until done and is free, but omits important details such as the return value, failure behavior, or what 'done' means. This is a partial disclosure, not a full one.
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?
Concise two-sentence description plus a parameter note. Front-loaded with purpose and usage. No unnecessary words or redundancies.
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?
Adequate for a simple single-parameter tool, but missing return-value information and behavior on failure. Without an output schema, the agent does not know what the response will contain. The description covers core usage but leaves clear gaps for a complete picture.
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 provides only a title 'Job Id' with no description (0% coverage). The description compensates by explaining job_id is the id returned by submit_video_job and gives an example format. This adds essential meaning beyond the schema.
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?
Clearly states the tool polls a video job until it is done. Uses a specific verb ('poll') and resource ('video job'), and distinguishes it from siblings by referencing the workflow: 'Use after submit_video_job returns a job_id.'
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?
Explicitly says when to use: 'Use after submit_video_job returns a job_id.' This provides clear context and ties into the sibling tool flow. It does not explicitly mention alternatives or exclusions, but the usage context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent video jobs. Free.
limit: max jobs to return, e.g. 20
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure responsibility. It only states the action and a cost feature, but omits whether the operation is read-only, any authentication requirements, output format, or error behavior. This is insufficient for a tool with zero annotation support.
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 extremely concise and front-loaded with the action. Every line earns its place: the purpose, a cost note, and a parameter explanation. No fluff.
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 a simple list tool with one optional parameter, the description covers the core purpose and parameter semantics. However, it does not mention return format, ordering, pagination, or usage context, and there is no output schema or annotations to fill these gaps. It is adequate but not rich.
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 has no parameter description, so the description's 'max jobs to return, e.g. 20' adds real semantic value by clarifying the limit's purpose. This compensates for the 0% schema description coverage, though it only covers a single simple parameter.
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 uses a specific verb ('List') and resource ('video jobs') with a scope ('recent'), clearly distinguishing it from siblings like get_job and submit_video_job. The purpose is unambiguous and directly 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?
There is no explicit when-to-use guidance or mention of alternatives. The only extra detail is 'Free.', which is a pricing note, not a usage recommendation. It does not differentiate from get_job for individual job retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List narration voices you can pass to submit_video_job. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds 'Free', which is a useful access/cost trait, and 'you can pass to submit_video_job', which clarifies the returned values are directly usable. It does not detail output format or pagination, but for a simple zero-parameter list operation these gaps are minor.
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 two short sentences with no filler. The primary purpose is front-loaded, and the secondary detail about cost is brief and relevant. Every word earns its place.
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 a no-parameter listing tool with no output schema, the description provides enough context: it returns narration voices that can be passed to submit_video_job. It could explicitly state the return format, but that is a minor omission given the straightforward nature of the operation.
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 has zero parameters, so the baseline is 4. There is no parameter documentation needed, and the description adds no unnecessary parameter-specific details.
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 uses a specific verb 'List' with a clear resource 'narration voices' and ties it to 'submit_video_job', which distinguishes it from the sibling job-related tools. It explicitly tells the agent what the tool does and how the output will be used.
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 clearly implies when to use this tool: before submit_video_job, to obtain valid voice options. It doesn't explicitly list exclusions or alternatives, but the tool's focused purpose and sibling set make those unnecessary. The mention of 'Free' also helps the agent understand there is no cost barrier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to pay, step by step. Read this if you got a 402 and are not sure what to do.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies the tool is informational ('How to pay, step by step') but doesn't explicitly state it's read-only or describe what the response looks like. For an info tool, the behavioral intent is sufficiently clear, but a more explicit disclosure would improve transparency.
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 a single, front-loaded sentence that immediately communicates the purpose and usage condition. Every word earns its place, with no fluff or repetition.
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?
Given the tool's simplicity (no params, no output schema), the description adequately covers the trigger (402) and the content (payment steps). It doesn't detail the exact return format, but for an info tool, this is not a critical gap.
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 has zero parameters and an empty schema, so description adds no param details, but none are needed. The absence of parameters is self-evident, and the baseline for 0 params is 4, which is appropriate here.
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 clearly states the tool's function: providing step-by-step payment instructions. It specifically mentions 'How to pay, step by step' and the trigger 'got a 402', distinguishing it from all sibling tools (video, jobs, voices, etc.).
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 explicitly says 'Read this if you got a 402 and are not sure what to do,' which clearly tells when to use the tool. It doesn't name alternatives, but no sibling tool serves a similar payment-info purpose, so the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell this server what you needed and could not get. Free — no payment required. Your input goes to the operator's queue and to a public board of unmet agent demand (contact details are never shared; entries are reviewed before publishing). Include what you would pay if you know.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| tried | No | ||
| contact | No | ||
| would_pay_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so exceptionally. It details data flow (operator queue, public board), privacy safeguards (contact details never shared), review process (entries reviewed before publishing), and cost (free). This is comprehensive for a simple submission tool.
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 three sentences long, starts with the core purpose in the first sentence, and each subsequent sentence adds essential context (cost, data handling, user guidance). There is no redundancy or filler, and the structure is easy to skim.
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 a lightweight tool with no output schema, the description explains the outcome (input goes to operator queue and public board) and the procedural details (review before publishing). The only minor gap is that it does not mention whether any confirmation or request ID is returned, but this is not critical for a simple submission tool.
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 description adds meaning to several parameters: 'what you needed' maps to need, 'Include what you would pay' relates to would_pay_usd, and 'contact details are never shared' addresses contact. However, the 'tried' parameter is never mentioned, and with 0% schema_description_coverage, the description only partially compensates for the missing schema-level explanations.
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 opens with 'Tell this server what you needed and could not get,' clearly identifying the action (submit a capability request) and the resource (the server's capability queue). It stands apart from sibling tools like fetch_video, get_job, or submit_video_job, which focus on video/job operations, making the purpose 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 statement 'Tell this server what you needed and could not get' implies the appropriate context: when an agent's need is unmet by existing tools. It also clarifies cost ('Free — no payment required'), which is relevant given a payment_info sibling exists. However, it does not explicitly name alternative tools or state when not to use it, so it lacks the explicit exclusion guidance seen in a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. What this server sells, what it will not do, and the exact limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool will describe what the server sells, what it will not do, and its limits, implying read-only, informational behavior. It doesn't detail response format or side effects but is reasonably transparent for a service info tool.
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 extremely concise, consisting of two short sentences that are front-loaded with the key instruction 'Start here.' Every word adds meaning, and there is no filler.
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 a zero-parameter informational tool with no output schema, the description adequately covers the needed context: it tells the agent what to expect (service summary, limitations) and positions the tool as the initial step. Nothing essential 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?
The tool has zero parameters, and the schema covers an empty object, so there are no parameter semantics to explain. The baseline score of 4 applies because there is nothing for the description to add.
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 clearly states the tool's purpose: it serves as the starting point for understanding what the server offers, its limitations, and exact limits. This distinguishes it from sibling tools that handle specific tasks like fetching videos or submitting jobs.
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?
'Start here' explicitly instructs the agent to use this tool first, setting clear usage context. It does not name alternative tools or specify when not to use it, but the directive to begin here is a strong usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a script into a finished 1080p video — narrated, cut to matched stock footage, subtitles burned in, audio normalized to −14 LUFS. Returns a job id; poll get_job, then fetch_video. Use when you need a publishable video and have only text. $0.60 per video in USDC on Solana — no account, no API key, no human in the loop.
script: narration body to speak (plain text) title: optional intro title shown for ~4s at the top voice: voice id from list_voices(), e.g. female_warm subtitles: burn-in subtitles (default true) speed: narration speed multiplier, e.g. 1.0 seed: stock-selection seed for reproducible visuals, e.g. 7
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| speed | No | ||
| title | No | ||
| voice | No | female_warm | |
| script | Yes | ||
| subtitles | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: asynchronous job submission ('Returns a job id'), output specifications (1080p, audio normalized), and cost ('$0.60 per video in USDC on Solana') including the absence of account/API key requirements. This is sufficient for understanding side effects and prerequisites.
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 well-structured: a concise first paragraph covering purpose, workflow, and cost, followed by a clean parameter list. Every sentence carries useful information with no fluff, achieving high information density without being wordy.
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?
Given the tool's complexity (6 params, no output schema, paid async job), the description is remarkably complete. It explains all inputs, the output (job id), the subsequent polling/fetching process, and the cost model, allowing an agent to confidently invoke and handle the result without missing context.
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 input schema has no property descriptions (0% coverage), so the description must and does explain every parameter. Each parameter is given a clear one-line explanation ('title: optional intro title shown for ~4s at the top', 'seed: stock-selection seed for reproducible visuals'), adding meaning well beyond the bare schema.
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 clearly states the tool's job: 'Turn a script into a finished 1080p video' with specifics like subtitles and audio normalization. It distinguishes from sibling tools by emphasizing the submission step and its direct outcome, making its role distinct from fetching or listing.
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?
It explicitly says 'Use when you need a publishable video and have only text', providing direct usage context. It also outlines the workflow ('Returns a job id; poll get_job, then fetch_video'), which tells the agent how to integrate with alternatives, effectively guiding tool selection and sequence.
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. Dates show when Glama detected each change.
request_capabilityfetch_videoget_joblist_jobslist_voicespayment_infoservice_infosubmit_video_jobClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
AI video generation API with x402 USDC payment. TTS voiceover, animated text.
Author, run, and publish AI video pipelines. Agents can pay per render with x402 USDC, no API key.
Pay-per-use AI and data tools via x402: image, video, music, voice, search, crypto. USDC.
Summarize YouTube videos or fetch transcripts. Pay-per-call via x402 (USDC on Base), no account.
Add one secure layer between your agents and this server.
Each tool has a distinct role in the video generation workflow: submit creates, get_job polls, fetch_video retrieves the result, list_jobs lists history, and the remaining tools cover voices, payment, service info, and feedback. There is no meaningful overlap between tools.
Most tools follow a verb_noun pattern (submit_video_job, get_job, fetch_video, list_jobs, list_voices), but payment_info and service_info use a noun_info pattern. This is a minor deviation; all names are clear, snake_case, and readable.
With 8 tools, the set is well-scoped for a video generation service. It covers job submission, monitoring, retrieval, listing, voice selection, and two informational endpoints, without unnecessary bloat or a feeling of incompleteness.
The core lifecycle is covered: submit, poll, fetch, and list jobs, plus listing voices and payment guidance. The only notable gap is the lack of job cancellation or update operations, but agents can work around this since the service is fire-and-forget.
