Skip to main content
Glama
Sign In
Tester Agent

Tester Agent

by datb2404981
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Đăng ký website cần kiểm thử

tester_register_project

Register a web project by URL for QA testing. Defaults to localhost and read-only access; enable remote QA sites or form writes with explicit flags.

Instructions

Đăng ký một dự án web bất kỳ theo URL. Mặc định chỉ chấp nhận localhost và chỉ đọc. Website QA từ xa cần allowRemote=true. Muốn AI tự bấm form trong QA phải bật allowWrites=true.

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>",
      "baseUrl": "<baseUrl>"
    },
    "name": "tester_register_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseUrlYesURL website web local hoặc QA.
projectYesTên ngắn duy nhất như my-web, shop-demo.
allowRemoteNo
allowWritesNo
environmentNolocal
allowedOriginsNoCác origin API/CDN cần thiết được cho phép ngoài baseUrl, chỉ dành cho môi trường QA.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full behavioral burden. It does well on the safety posture, disclosing that registration is localhost-scoped and read-only unless explicitly widened, which is non-obvious and security-relevant. It says nothing about idempotency, what happens when the project name already exists, persistence of the registration, or what the call returns, which is a notable gap for a mutating/creating tool.

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?

Three short sentences: purpose first, then the two gating flags in escalating order of permission. Zero filler and well front-loaded. It is lean to the point that the environment parameter never gets a mention, but that is a completeness issue rather than verbosity.

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?

Six parameters, no annotations, no output schema, and a creation-style operation means the description should do more. It covers the security gates well but leaves the environment parameter unexplained and gives no sense of the result or failure modes, which is thin for a tool that establishes the scope for all downstream browser tools.

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 description coverage is 50%, and the description compensates for the two undocumented booleans by explaining what allowRemote and allowWrites actually gate. That is genuine added meaning. However, the environment enum (local/qa) is undocumented in both schema and description, and its interaction with allowRemote is left ambiguous, so half the surface still relies on inference.

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 opens with a specific verb+resource: registering an arbitrary web project by URL. That is concrete and distinguishable from list-oriented siblings like tester_projects. What it does not do is name or contrast any sibling, so an agent must infer the boundaries itself.

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 gives real conditional guidance: default is localhost-only and read-only, remote QA requires allowRemote=true, and AI-driven form submission requires allowWrites=true. These are exactly the decision points an agent faces. There is no explicit statement of when not to use this tool or which sibling handles an already-registered project.

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