Skip to main content
Glama
Sign In

Stomio

by io.stomio.api
OverviewDiscussionsAdmin

createTask

Creates a new task in this beta project and appends it to the end of the task list. A task is a container for the steps the testers work through; add those with createStep. The response's ready is false until the task has at least one step: that is expected right after creation, not an error, and nothing to tell the user about; just continue with createStep. Creating always appends, so create tasks in the order testers should meet them, or place them afterwards with updateTasksOrder. On a draft or scheduled beta project the change is applied immediately. On a running or paused beta project the change is STAGED: testers do not see it until commitTaskChanges publishes all staged changes (revertTaskChanges discards them; getBetaTasks with version 'unpublished' shows the staged state). While staging, these tools accept BOTH the live id and the staged id of a task or step, but always respond with the STAGED row — expect ids you did not pass in, with liveVersionId linking back to the live row. Content of finished or archived beta projects cannot be edited.

Input Schema

NameRequiredDescriptionDefault
nameYesThe task name (1 to 128 characters).
optionalNoWhether testers may skip this task: they get a Skip control and a skipped task counts as done. Defaults to false. Only tasks of Stomio-placement beta projects can be optional, and a task cannot be both optional and scheduled with availableDate: the two are mutually exclusive.
productIdYesID of the beta project to query. Get valid IDs from the listProducts tool.
descriptionNoWhat the testers should do in this task (up to 512 characters of text; basic HTML is allowed).
availableDateNoISO 8601 date-time before which the task shows as locked and testers cannot start it. Omit for available immediately; null (updateTask) clears an existing date. A date past the beta end date is accepted here but blocks publishBeta and commitTaskChanges until fixed. Mutually exclusive with optional: a task can be optional or scheduled, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With annotations only saying this is a non-read-only, non-destructive mutation, the description adds substantial behavior beyond them: staging on running or paused projects, the need for commitTaskChanges to publish, revertTaskChanges to discard, and getBetaTasks with version 'unpublished' to inspect staged state. It also explains that responses return staged ids with liveVersionId links, and that ready=false after creation is expected rather than an error.

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

Conciseness4/5

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

The description is front-loaded with the creation action and appending behavior, then moves into step guidance and staging semantics. It is longer than typical but dense with operational detail; most sentences carry necessary context, though the staging paragraph is quite dense.

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?

For a mutation tool with no output schema, the description covers the important response behavior (ready=false, staged ids, liveVersionId), lifecycle edge cases (draft versus running projects, archived projects), and next-step guidance. It gives an agent everything needed to invoke the tool correctly in context.

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, and the description adds useful cross-parameter meaning: optional and availableDate are mutually exclusive, and optional only works for Stomio-placement beta projects. It also clarifies ordering behavior around availableDate, though most individual field semantics remain in the schema.

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?

The description states a specific verb and resource: creates a new task in this beta project and appends it to the end of the task list. It also distinguishes the tool from siblings by directing step creation to createStep and reordering to updateTasksOrder, so an agent can identify its unique role.

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?

It gives explicit when-to-use context: create tasks in tester order because creation always appends, use updateTasksOrder for later placement, and use createStep to add steps. It also explains lifecycle constraints: edits are immediate on draft or scheduled projects, staged on running or paused projects, and blocked for finished or archived projects.

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

All Stomio toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources