Skip to main content
Glama
Sign In
Swipium

Swipium

by GeroPalombo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Resume after providing input

qa_continue_from_blocker

Answer a needs_input prompt like credentials, OTP, or platform choice so QA can resume. Secrets are redacted on receipt; non-secret answers map to the next call's args.

Instructions

Answer a needs_input question (credentials, OTP, platform, device, monorepo target) and get the next call. Secrets (passwords/OTP/tokens) are redacted at once and never echoed or logged (flows use ${VAR}). Non-secret choices map onto the re-invocation args. Returns accepted, ignored[], projectRoot, nextAction; with no new consent needed it starts the resumed job (jobId).

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": {
      "sessionId": "<sessionId>",
      "kind": "<kind>"
    },
    "name": "qa_continue_from_blocker"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesThe needs_input kind (e.g. credentials, monorepo_target).
valuesNoField name > value. Secret fields are redacted on receipt.
sessionIdYes
secretFieldsNoSecret keys (default: password/otp/token-like names).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so mutation and idempotency status are known structurally. The description still adds real value beyond them: immediate secret redaction, no echo/logging, the ${VAR} flow convention, and the fact that it may kick off the resumed job (jobId) — though it omits error behavior for bad kinds or expired sessions.

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 core action and secret-handling guarantee are front-loaded in the first two sentences, with return fields trailing. It is dense and slightly run-on but every clause carries information.

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 state-mutating tool with no output schema, listing accepted, ignored[], projectRoot, nextAction and jobId substitutes well for a return contract. What is missing is failure/blocker-recurrence behavior and how sessionId lifetime works.

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 75%, so the schema already documents kind, values, secretFields and their defaults. The description reinforces the kind enum-by-example and the rule that non-secret choices map onto re-invocation args, but adds no format or validation detail beyond what the schema provides.

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 description gives a specific verb+resource: answer a pending needs_input question and receive the next call, enumerating the kinds it handles (credentials, OTP, platform, device, monorepo target). It is distinct from qa_explain_blocker in intent, though it never names that sibling to contrast explicitly.

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 clearly establishes the trigger condition — there is an outstanding needs_input blocker whose kind and values you supply — and implies non-secret choices become re-invocation args. It stops short of naming an alternative (e.g. qa_explain_blocker) or stating when not to call it.

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