Skip to main content
Glama
Sign In

CheckMyApp

by io.github.sorokinvj
OverviewDiscussionsAdmin

Check a finding again

recheck
Destructive

Confirm a fix in one call, for the price of the journeys it touched: re-walks only the journeys where a finished check's open findings (or the one numbered) were seen, on the same app or url, with deploy_sha for the build with the fix (an extension is walked whole). When it ends, get_review of the new run_id has recheck.findings — gone (marked fixed on the original check, with the build), still_there, or not_verified. Needs a key that can start checks.

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": {
      "run_id": "<run_id>"
    },
    "name": "recheck"
  }
}

Input Schema

NameRequiredDescriptionDefault
teamNoAct in another of your teams, by its name or id (whoami lists them). Omitted: the key's own team
run_idYesThe finished check whose findings to confirm gone
findingNoOne finding's number; omitted, every open finding of the check
deploy_envNoWhere that build is, e.g. production or preview
deploy_shaNoThe build with the fix — a finding gone is marked fixed on it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the destructiveHint/openWorldHint annotations, it discloses the real side effect (findings are marked fixed on the original check with that build), the authorization requirement (a key that can start checks), the cost model (only the journeys touched, an extension walked whole), and the three result states returned on the new run's review.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is compact and front-loads the outcome, but the single run-on sentence is laden with figurative phrasing ('for the price of the journeys it touched') and a parenthetical that interrupts parsing of an already dense clause.

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?

For a destructive, open-world mutation with five parameters and no output schema, it covers authorization, side effects, scope control, cost, and how to retrieve results via get_review. Nothing essential for calling it correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning: run_id must refer to a finished check, finding scopes to one finding versus every open finding, and deploy_sha is the build on which 'gone' findings are marked fixed.

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 gives a specific verb+resource: re-walk only the journeys where a finished check's open findings were seen, to confirm a fix. It distinguishes itself from a full check by its narrow scope, but introduces undefined domain jargon ('journeys', 'an extension is walked whole') that an agent must infer from siblings like list_scenarios.

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 states the trigger clearly: use after a build containing the fix, supplying deploy_sha, to confirm findings are gone. The cost-based differentiation from a full check is implied but the sibling that performs a full check (start_check) is never named, and there are no explicit exclusions.

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

All CheckMyApp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources