Skip to main content
Glama
Sign In

OverlayQA

by com.overlayqa
OverviewDiscussionsAdmin

Verify issue

verify_issue
Idempotent

Check whether a resolved, verified, or closed issue is fixed on its public page. Requires original screenshot evidence and a verifiable issue type. Uses your verification allowance and returns the saved verdict, explanation, confidence and after-screenshot evidence. Does not change issue status. Caveats, failures, inconclusive and error results are not unconditional passes. Login-required and localhost pages need the extension. Availability follows the verification rollout. Reuse requestId when retrying the same check.

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": {
      "issueId": "<issueId>",
      "requestId": "<requestId>"
    },
    "name": "verify_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
issueIdYesIssue UUID or display ID, such as OQ-12
requestIdYesNew UUID per verification; reuse only to retry that same check

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that it consumes a verification allowance, does not change issue status, returns a saved verdict/explanation/confidence/after-screenshot, and that caveats, failures, inconclusive and error results are not unconditional passes. This adds real behavioral context on top of readOnlyHint=false and idempotentHint=true.

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 with the core action, and each subsequent sentence carries a distinct piece of information (prerequisites, side effects, return values, caveats, constraints). The telegraphic, choppy phrasing costs a little readability, keeping it out of the top score.

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?

With no output schema, the description correctly supplies the return shape (verdict, explanation, confidence, after-screenshot) and covers failure modes, extension requirements, and allowance consumption. A mutation-adjacent, allowance-consuming tool could still say more about what a verdict value means or allowance limits, so it is strong rather than exhaustive.

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 coverage is 100%, so both parameters (issueId, requestId) are fully documented, establishing a baseline of 3. The description's requestId guidance largely restates the schema's own 'reuse only to retry that same check' note, adding no meaningful new semantic detail.

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?

States a specific verb (check/verify) and resource (issue) with an explicit scope: resolved, verified, or closed issues on their public page. It is clearly distinguishable from siblings like get_issue_verifications (which retrieves stored verdicts) or get_issue (which fetches the issue 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?

Gives clear preconditions for use: original screenshot evidence, a verifiable issue type, extension for login-required/localhost pages, and rollout-dependent availability. It also explains requestId reuse semantics for retries. It does not explicitly name a sibling alternative or state when not to use this tool, so it falls short of a 5.

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

All OverlayQA 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