Skip to main content
Glama

Uxia

by app.uxia.platform
OverviewDiscussions(5)Admin

Update Task

update_task
DestructiveIdempotent

Edit task/scenario/stopCondition wording by blockId. Only supplied fields change; all other settings are preserved. Empty strings clear wording. Use update_test_block for experience or credential changes. No launch. The concrete action the tester performs in the product. When drafting or suggesting wording, write one short sentence, usually 10–25 words: [action verb] + [single concrete target] + [essential method or constraint]. Describe one coherent goal; naturally paired actions are fine, but split independent goals into separate tasks. If multiple items could match, identify one by name or position; avoid "any item". Name the in-app mechanism when needed. Keep motivation and backstory in scenario, observable completion criteria in stopCondition, and judgments or research objectives in follow-up survey questions. Omit step-by-step navigation and unnecessary detail. Example: "Book a table for 2 at Bar Mut for tonight at 8:00 PM." Preserve supplied or accepted wording unless the user requests a rewrite or delegates wording choices. When drafting or suggesting scenario wording, write 1–3 short sentences in second person, present tense ("You are…", "You have…"). Describe a believable situation and a concrete triggering moment explaining why the tester needs to act now. Keep the action in the task; do not repeat it here. Example: "It is Friday evening, you are exhausted from work, and you do not want to cook tonight." Preserve supplied or accepted wording unless the user requests a rewrite or delegates wording choices. When drafting or suggesting stopCondition wording, write one short sentence starting with "Stop when". Name one observable on-screen state detectable from a screenshot or DOM that marks the task’s natural completion. Avoid alternative endings, user feelings and off-screen events such as receiving an email; do not stop mid-flow. Example: "Stop when the order confirmation page displays the order number and total amount." Preserve supplied or accepted wording unless the user requests a rewrite or delegates wording choices.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskNoDraft one short sentence, usually 10–25 words: action + one target + essential constraints. Preserve accepted wording.
testIdYes
blockIdYes
scenarioNoDraft 1–3 short sentences in second person, present tense: situation + reason to act now. Do not repeat the task.
stopConditionNoDraft one short "Stop when" sentence naming an observable on-screen state at task completion. No alternatives or off-screen events.
expectedRevisionNoLegacy compatibility only; ignored. Draft revisions are resolved automatically.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOpen the draft in Uxia.
testIdNo
blockIdNoServer-assigned ID of the added block. Use it for subsequent edits and references.
editableNo
definitionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / expectedRevision / description
      Added value: +"Legacy compatibility only; ignored. Draft revisions are resolved automatically."
    • changedInput schema / required
      Previous value: -[
-  "testId",
-  "expectedRevision",
-  "blockId"
-]New value: +[
+  "testId",
+  "blockId"
+]
  2. Changed4 schema fields changed
    • addedInput schema / properties / scenario / description
      Added value: +"Draft 1–3 short sentences in second person, present tense: situation + reason to act now. Do not repeat the task."
    • addedInput schema / properties / stopCondition / description
      Added value: +"Draft one short \"Stop when\" sentence naming an observable on-screen state at task completion. No alternatives or off-screen events."
    • addedInput schema / properties / task / description
      Added value: +"Draft one short sentence, usually 10–25 words: action + one target + essential constraints. Preserve accepted wording."
    • addedOutput schema / properties / blockId
      Added value: +{
+  "description": "Server-assigned ID of the added block. Use it for subsequent edits and references.",
+  "type": "string"
+}
  3. Changed6 schema fields changed
    • removedInput schema / properties / scenario / $ref
      Removed value: -"#/properties/task"
    • addedInput schema / properties / scenario / maxLength
      Added value: +500
    • addedInput schema / properties / scenario / type
      Added value: +"string"
    • removedInput schema / properties / stopCondition / $ref
      Removed value: -"#/properties/task"
    • addedInput schema / properties / stopCondition / maxLength
      Added value: +500
    • addedInput schema / properties / stopCondition / type
      Added value: +"string"
  4. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description adds meaningful semantics: 'Only supplied fields change; all other settings are preserved' and 'Empty strings clear wording', which explains the destructive behavior hinted at by destructiveHint. This is genuine value the annotations cannot convey.

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

Conciseness2/5

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

The description is front-loaded correctly but then balloons into hundreds of words of drafting guidance, with the sentence 'Preserve supplied or accepted wording unless the user requests a rewrite or delegates wording choices' repeated verbatim three times. The behavioral core (partial update, clearing, sibling routing) could be stated in a few sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the partial-update/clearing behavior is covered. However, the bulk of the text is authoring guidance rather than tool-operational context, and nothing addresses the required testId or the ignored expectedRevision parameter, leaving signal diluted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67% and the description's drafting rules for task/scenario/stopCondition largely restate what the schema already documents. The one addition beyond the schema is 'Empty strings clear wording', which is not stated in the parameter definitions. Baseline 3 is appropriate given the schema carries most of the load.

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 opening sentence gives a specific verb and resource — editing task/scenario/stopCondition wording by blockId — and explicitly separates the tool from update_test_block, which handles experience/credential changes. The purpose is clear despite the long tail of drafting guidance that follows, which is about content authoring rather than what the tool does.

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 states a concrete boundary: 'Use update_test_block for experience or credential changes. No launch.' This routes the agent away from the wrong sibling and clarifies the tool does not trigger execution. It does not, however, address when not to edit wording at all (e.g., after a test is running).

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

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