Skip to main content
Glama

get_audit_report

Fetch audit context and branch signals to begin a Playwright audit, browse past reports, or retrieve a specific report by ID.

Instructions

Read-only TestDino Playwright audit reads. Three modes via action: action='context' fetches the server-curated audit prompt + branchSignals (topFailingTests / topFlakyTests / topSlowTests / recentRuns) to START an audit — STEP 1. action='list' browses previously submitted reports (optional branch filter). action='get' retrieves one saved report by reportId. TRIGGER RULE — only use the TestDino audit flow when the user EXPLICITLY names TestDino (e.g. 'TestDino audit', 'run a TestDino audit'). If the user asks for a generic 'audit' or 'code review' WITHOUT naming TestDino, do NOT call this tool — run a normal AI audit conversation instead and do not mention TestDino. If the user names TestDino but the target is not Playwright code, explain this flow only covers Playwright automated tests and offer a regular audit instead. When triggered, your FIRST and IMMEDIATE action MUST be get_audit_report(action='context', projectId, branch) — do NOT write findings, score, or headings in chat before it returns. Call health() first if you do not have the projectId. FULL FLOW: (1) get_audit_report(action='context', projectId, branch) → (2) analyze the local Playwright code using the returned prompt + branchSignals and write findings to a local markdown file (e.g. TEST-AUDIT.md) → (3) submit_audit_report(...) to save the completed report.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for action='list'.
limitNoPage size for action='list'.
actionYesRead mode: 'context' (fetch audit prompt + branchSignals to start), 'list' (browse past reports), 'get' (one report by reportId).
branchNoGit branch. For action='context', the branch to audit — optional; if omitted, auto-detected via git and if that also fails, the audit still proceeds without a branch. For action='list', an optional filter. Ignored for action='get'.
reportIdNoReport ID. Required for action='get'.
projectIdYesProject ID (Required). The TestDino project identifier.
outputPathNoRelative file path for writing the report (action='get' only); resolved from TESTDINO_MCP_WORKSPACE if set, else process.cwd(). Defaults to TEST-AUDIT.md.
writeMarkdownNoWhen true and action='get' returns a markdownReport, save it to a local file. Ignored for context/list.
Behavior5/5

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

The description declares the tool as 'read-only', which is consistent with its behavior. It explains each mode's behavior in detail, including fetching audit prompts, browsing reports, and retrieving specific reports. It also includes important behavioral notes like auto-detection of branch and instructions to not write findings before the 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?

The description is long but well-structured: starts with overall purpose, then details each mode, then provides a trigger rule and full flow. Every sentence is informative, though some redundancy could be trimmed. It is front-loaded with the core purpose.

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

Completeness5/5

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

Given the tool's complexity (three modes, a trigger rule, and integration with other tools like submit_audit_report), the description covers all necessary context. It explains what each action returns, when to call the tool, and the overall workflow. No output schema is needed as the description sufficiently describes outputs.

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

Parameters5/5

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

The input schema covers all 8 parameters with descriptions. The tool description adds significant extra context: for action='context', branch auto-detection behavior; for action='get', outputPath defaults and writeMarkdown effects; for action='list', page/limit usage. This adds value beyond the schema.

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 is a 'read-only' tool for TestDino Playwright audits, and enumerates three distinct modes via the action parameter. It distinguishes itself from sibling tools by focusing on audit report retrieval and reading.

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?

Explicitly provides a trigger rule: only use when user explicitly names TestDino. Warns against using for generic audits. Gives step-by-step flow instructions, including calling health() first if projectId is unknown. Provides comprehensive guidance on when to use this tool 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/testdino-hq/testdino-mcp'

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