Skip to main content
Glama
Sign In
Tester Agent

Tester Agent

by datb2404981
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

AI bắt đầu hoặc kết thúc một test case

tester_browser_case

Start or finish a simple browser check or structured E2E flow by declaring steps and validating each step with assertions to prevent incomplete test runs.

Instructions

kind=check dành cho kiểm tra đơn giản. kind=flow dành cho E2E, phải khai báo trước các bước và kiểm chứng từng bước bằng tester_browser_step và assertion. Thiếu bước sẽ BLOCKED.

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": {
      "project": "<project>",
      "phase": "<phase>"
    },
    "name": "tester_browser_case"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNocheck
nameNo
phaseYes
stepsNo
projectYes
categoryNofunctional
expectedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

C2.9/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It usefully discloses one consequence not found in the schema: if steps are missing, the case is marked BLOCKED. It says nothing about state transitions between `start` and `finish`, whether `finish` requires a prior `start`, or what a call returns.

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?

It is a tight three sentences with no filler and no repetition. The content is dense and useful, but it is not front-loaded with purpose; it opens directly on parameter mechanics, which costs a bit of orientation.

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

Completeness2/5

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

This is a stateful lifecycle tool with 7 parameters, no annotations, no output schema, and no parameter documentation. Given that complexity, a description that omits the meaning of `start` versus `finish` and the result of a call leaves the agent under-informed before invoking it.

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

Parameters2/5

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

Schema description coverage is 0% across 7 parameters, so the description must compensate, but it only explains `kind` and hints at `steps` and `expected`. `phase`, `project`, `name`, and `category` are undocumented in both places. The `phase` enum in particular drives the tool's entire start/finish lifecycle, yet goes unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never states what the tool itself does: it never says it opens or closes a test case, and that action is contained only in the title. Instead, all three sentences are about the `kind` values. An agent can infer that it configures a case from `kind`, `steps` and `phase`, but the scope of the tool remains vague.

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?

It does give real selection guidance for one enum: use `kind=check` for simple checks and `kind=flow` for E2E work. It also points to `tester_browser_step` and assertion for verification. However, it gives no guidance on `phase=start` versus `phase=finish`, no prerequisites, and no comparison with `tester_browser_start` or `tester_browser_finish` beyond the sibling name.

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