swarme_ai_runEnqueue a curated AI model using the authenticated account credit balance.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| prompt | Yes | ||
| options | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses two behaviors: the operation is queued ('Enqueue') rather than synchronous, and it consumes the authenticated account credit balance. However, it omits details like what happens with insufficient credits, whether the operation is reversible, and what the queued job returns beyond what the output schema might provide.
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 with no filler. It communicates the primary action and a key cost constraint efficiently, though it sacrifices useful detail for brevity.
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 tool with three undocumented parameters and an output schema, the description is too thin. It does not explain how to identify a valid slug, what prompt constraints matter beyond the schema's maxLength, or what options accepts. The lack of usage guidance also leaves the agent uncertain about when this tool is the right choice among many siblings.
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%, and the description does not explain slug, prompt, or options at all. An agent must guess what 'curated AI model' implies for the slug parameter and what options might contain. The description adds no semantic value for any of the three parameters.
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 identifies a specific action ('Enqueue') and resource ('curated AI model'), and adds the meaningful constraint of using the account credit balance. It does not explicitly differentiate from sibling tools like swarme_tool_run, and 'curated' is somewhat vague, but the core purpose is clear.
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?
No guidance is provided about when to use this tool versus alternatives such as swarme_tool_run, swarme_experiment_create, or swarme_ai_models. The description implies a use case but states no conditions, exclusions, or prerequisites beyond having a credit balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are grouped into distinct resource families (account, AI, capabilities, discover, experiments, tool runs, uploads, vault), so most are easy to tell apart. However, multiple 'status' tools and the two Vault metadata tools (documents and summary) could be confused without reading the descriptions carefully.
All tools share a consistent swarme_ prefix and snake_case style, making them predictable. The pattern is not uniformly verb_noun, and there is a plural mismatch between swarme_capabilities_search and swarme_capability_describe, but the naming is generally coherent.
22 tools is on the heavy side and above the typical 3-15 range for a focused MCP server. While the platform covers many domains and each tool has a role, several status-related tools could have been consolidated.
Core workflows like tool runs, experiments, AI model jobs, and Vault fills are well covered. Notable gaps remain: no cancellation for AI jobs or experiments, no listing endpoints for runs/experiments, no Vault field read/delete, and the upload session has no companion completion/status tool.