Skip to main content
Glama
Sign In

Testsy

by dev.testsy
OverviewDiscussionsAdmin

Update a test

update_test
Idempotent

Change a test: its title, start address, requirement, plan or options. Only the fields you pass change; within options, only the options you pass change and the others keep their values.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "testId": "<testId>"
    },
    "name": "update_test"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoNew start address
planNoA plan from plan_test: {title, startUrl, steps[], checks[], record[], assumptions[], credentials[]}. Stored as the approved checklist; the tester follows it as written.
titleNoNew title
deviceNoApps: phone or tablet (see list_devices)
testIdYesTest id (t_…)
optionsNoTest options, all optional: device (desktop | tablet | mobile; websites), timeoutMinutes (2-20; 20 when left out, the app sets 15), recordVideo (default true), trackers (block | allow; websites, default block), jsErrors (report | fail; websites, default report: errors from the site's own scripts are reported and fail the run only when one breaks a step; fail = any of them fails it), credentials (names of the project's sign-in accounts), services (email = its own mailbox, sms and call = its own phone number, http = the project's endpoints; sms, call and http need a paid plan), devices (1 or 2 phones; apps), platform (web | android | ios), appId and buildId (apps), buildUrl (apps: an https link to the build, downloaded every run), orientation (apps: default | portrait | landscape — the screen's shape when the run starts; default is the device's own).
osVersionNoApps: the OS version, latest (default) or a version — iOS: iOS 27, iOS 26, iOS 18, iOS 17; Android: Android 16, Android 15, Android 14, Android 13, Android 12, Android 11, Android 10 (see list_devices)
orientationNoApps: the screen's shape when the run starts — default (the device's own: phones and iPads upright, Android tablets on their side), portrait or landscape. The test may still rotate the device during the run.
requirementNoNew requirement text

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety is partly covered. The description still adds the most important behavioral trait not captured there: patch semantics, both at top level and one level deep inside options, which tells the agent how untouched values are preserved.

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

Conciseness5/5

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

Two short sentences, with the change scope stated first and the nested-merge caveat immediately after. Nothing is repeated from the schema and there is no filler.

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

Completeness4/5

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

For a 9-parameter mutation tool with nested objects and no output schema, the description covers the essential partial-update behavior and the one non-obvious nested case. It leaves out whether updates affect history or pending runs, but no critical calling information is missing.

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 100% and the per-parameter descriptions are already rich, so the baseline is 3. The description does add the merge rule that the schema does not state, but its field enumeration omits device, osVersion and orientation, which could mislead an agent about what is updatable.

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?

"Change a test" pairs a specific verb with a specific resource and then enumerates the editable fields (title, start address, requirement, plan, options). That is enough for an agent to separate it from create_test, delete_test and get_test without opening a schema, though it never names any sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the verbs and the required testId make clear this is for modifying an existing test, not creating one. There is no explicit statement of when to prefer this over create_test, plan_test or add_test_file, and no prerequisites or exclusions are given.

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

All Testsy toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources