Skip to main content
Glama
Sign In

Testsy

by dev.testsy
OverviewDiscussionsAdmin

Add a sign-in account

add_credential

Store a sign-in account the tester can use. The password is encrypted, never returned, and never sent to the tester's AI: the tester types it. Tests refer to the account by name ("Sign in as the account "customer""). Through MCP the password passes through your AI agent: prefer adding passwords in the web app or over the REST API from a secret store.

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": {
      "projectId": "<projectId>",
      "name": "<name>",
      "username": "<username>",
      "password": "<password>"
    },
    "name": "add_credential"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesName tests use, for example customer (up to 60 characters)
siteNoSite it belongs to, optional
passwordYesPassword (write-only)
usernameYesUsername or email
projectIdYesProject id (p_…)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

The annotations only say readOnly=false, destructive=false, openWorld=false, idempotent=false; the description adds substantial security behavior on top: the password is encrypted, never returned, and write-only, plus a caution that over MCP the secret transits the agent. It does not cover what happens on a duplicate name or whether a returned identifier exists, which keeps it from a 5.

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?

Front-loaded: the verb and resource come first, then the secret-handling facts, then the safer alternative channel. There is slight tension between "never sent to the tester's AI" and "the password passes through your AI agent" that costs a read, but no sentence is 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 write tool with no output schema, the description covers the security profile, the naming convention, and the preferred alternate channel, which is most of what an agent needs. It omits what the call returns (e.g., a credential id) and how duplicate names are handled, which are the remaining gaps.

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 100%, so the schema already documents all five parameters, so the baseline is 3. The description reinforces that password is write-only and never returned, and clarifies that name is the handle tests reference, but adds little syntax or format detail beyond the schema.

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?

"Store a sign-in account the tester can use" gives a specific verb (store/add) and resource (sign-in credential), which cleanly separates it from add_endpoint, create_project, and the list_/delete_ credential siblings. It stops short of explicitly naming an alternative tool, but the resource distinction is unambiguous.

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

Usage Guidelines5/5

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

It describes how the stored account is consumed downstream ("Tests refer to the account by name") and gives an explicit when-not-to-use-this-channel: prefer the web app or REST API from a secret store for passwords. That is a clear routing decision an agent can act on.

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