Skip to main content
Glama
testdino-hq

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update Exploratory Session

update_session
Destructive

Modify an existing exploratory session by updating selected fields such as name, mission, state, tags, or environment; set status to closed to freeze it as done.

Instructions

Modify an existing exploratory session. Send only fields you want to change inside the updates object. Requires write permission. Allowed fields: name, mission, sessionType, config, environment, releaseId, assigneeUserId, state, estimate, tags, linkedIssues. Pass updates.status="closed" to close the session (same as the UI "Close session" button: freezes it, snaps state to the project's "Done" option). This is not reversible via MCP. Files cannot be added over MCP — tell the user to use the TestDino UI. IMPORTANT: updates.tags must be a JSON array of strings — e.g. ["exploratory","auth"] — NOT a comma-separated string.

Input Schema

NameRequiredDescriptionDefault
updatesYesFields to update: name, mission, sessionType, config, environment, releaseId, assigneeUserId, state, estimate, tags, linkedIssues. status="closed" closes the session.
projectIdYesProject ID
sessionIdYesInternal _id or counter-style ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.3
    • changedInput schema / properties / updates / description
      Previous value: -"Fields to update: name, mission, sessionType, config, environment, releaseId, assigneeUserId, state, estimate, tags, linkedIssues, attachments. status=\"closed\" closes the session."New value: +"Fields to update: name, mission, sessionType, config, environment, releaseId, assigneeUserId, state, estimate, tags, linkedIssues. status=\"closed\" closes the session."
  2. Changed6 schema fields changedv2.2.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / projectId / description
      Previous value: -"Project ID (required)."New value: +"Project ID"
    • changedInput schema / properties / sessionId / description
      Previous value: -"Internal _id or counter-style ID (required)."New value: +"Internal _id or counter-style ID"
    • addedInput schema / properties / updates / additionalProperties
      Added value: +{}
    • changedInput schema / properties / updates / description
      Previous value: -"Fields to update: name, mission, sessionType, config, environment, releaseId, assigneeUserId, state, estimate, tags, linkedIssues, attachments."New value: +"Fields to update: name, mission, sessionType, config, environment, releaseId, assigneeUserId, state, estimate, tags, linkedIssues, attachments. status=\"closed\" closes the session."
  3. Addedv1.0.10

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint=true annotation by explaining exactly what closing does (freezes the session, snaps state to the project's 'Done' option) and that it is not reversible via MCP. It also flags the permission requirement and the MCP capability gap for files.

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?

Six sentences, each carrying distinct payload — purpose, partial-update rule, permission, field list, close semantics, file limitation, tag format — with the purpose front-loaded and no filler.

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 destructive 3-parameter mutation with a free-form nested `updates` object and no output schema, the description covers everything an agent needs: which keys are allowed, the one special value, the format trap on tags, and irreversibility.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds real semantics the schema lacks: the precise JSON-array format for updates.tags with a worked example, the contrast with a comma-separated string, and the meaning of passing updates.status="closed".

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?

Opens with a specific verb+resource ("Modify an existing exploratory session") that an agent can immediately separate from create_session, get_session and list_sessions. It further scopes the operation by enumerating the updatable fields.

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?

Gives clear operating context: send only the fields you want changed, write permission is required, and file attachment must be handed off to the TestDino UI. It stops short of naming sibling tools (e.g., use create_session to create one) or stating when not to use this tool.

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

Deploy Server

Other Tools