Skip to main content
Glama

QA audit: auto-login per role and test the whole API

qa_audit

Scans project code for API endpoints, logs in as each role, runs test suite, and generates per-role and combined QA audit reports.

Instructions

The QA one-call workflow. Provide the project path and a list of role credentials (email/username + password). The tool detects the base URL and login endpoint, logs in as each role, runs the test suite per role (read-only by default), and writes a per-role + combined report. Set includeWrites=true only against a throwaway/staging env.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesProject root path.
rolesYesCredentials per role, e.g. [{role:'admin',email:'a@x.com',password:'…'}].
baseUrlNoAPI base URL. Omit to auto-detect from the code.
loginPathNoOverride login endpoint path.
roleScopedNoTest each role only on endpoints its route-guard allows (plus unguarded ones), so you get more real 200s and far fewer 403/404s. Set false for full coverage.
concurrencyNo
includeWritesNoInclude POST/PUT/PATCH/DELETE tests. Only for throwaway/staging envs.
includeDestructiveNoAlso test session-breaking endpoints (logout, refresh-token, delete-account, password reset, register). Off by default — testing logout revokes your own token.
maxRateLimitWaitMsNoMax ms to pace a request when the server's rate-limit budget is low. Raise toward the reset window (e.g. 900000) for exhaustive coverage under strict limits.
Behavior5/5

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

With no annotations, description fully discloses behavior: auto-detection of base URL and login endpoint, per-role login, read-only default, report generation, rate-limit pacing, and token revocation risks for includeDestructive. Very transparent.

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?

Four sentences, front-loaded with purpose, no filler. Each sentence adds essential context without redundancy.

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?

Covers workflow and parameter behaviors well, but lacks description of output format or report structure. Given no output schema, the description should mention what the tool returns. Still adequate for complex tool.

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

Parameters4/5

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

Schema coverage is 89% (high), so baseline 3. Description adds value by clarifying defaults (read-only), usage constraints (includeWrites only for throwaway), and side effects (includeDestructive token revocation). Exceeds schema alone.

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?

The description clearly states it's a QA one-call workflow that logs in as roles, runs tests, and generates combined reports. It distinguishes from siblings like 'run_tests' (no login) and 'full_audit' (possibly different scope).

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?

Provides explicit guidance: 'Set includeWrites=true only against a throwaway/staging env' and cautions about includeDestructive revoking tokens. Implicitly contrasted with siblings via tool name and description, but lacks explicit when-to-use vs alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hassan-Jamal/Automated_API_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server