Skip to main content
Glama

staleness_check

Compare findings against git history to detect stale code issues. Returns file status as current, modified, renamed, deleted, or unknown to show which findings need re-review.

Instructions

Check if findings are stale by comparing against git history.

Staleness is checked against each finding's NEWEST observation: a deduplicated re-observation records its commit in the occurrence ring, and that commit — not the frozen first-report reported_at_commit — is what the file is compared from; findings with no ring fall back to the first report. Each result carries checked_commit, the commit the verdict was computed against.

Returns file_status for each finding:

  • current: file unchanged since finding was reported

  • modified: file changed but still exists

  • renamed: file was renamed/moved

  • deleted: file no longer exists

  • unknown: can't determine, with a reason naming which question could not be answered — no provenance data, an unreachable commit, a path outside this repository's worktree, a path the reported commit never contained (a glob, free text, or a file added later), an empty or malformed value, a path that is neither a file nor a directory, or a git/stat call that failed

Args:

  • finding_id: Check a single finding (e.g. CB-1)

  • status: Filter by finding status (default: open)

  • category: Filter by category

  • file: Filter by file path (substring match)

  • resolve_anchors: Also resolve each finding's location anchor against HEAD, so a record says where the reported LINES are now and not only what became of the file. OFF by default: this query permits ten thousand rows and already spends git per file. Every record carries the cheap half of the summary either way — whether the card has an anchor at all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNo
statusNo
categoryNo
finding_idNo
resolve_anchorsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.2.2

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden; it discloses the dedup/re-observation commit logic, the fallback to first report, checked_commit, every unknown reason, and the default/perf behavior of resolve_anchors. This is considerably more transparent than required.

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?

Front-loaded one-line summary, then structured statuses before params. Although detailed, the length is justified by the tool's complexity and every section serves selection or invocation; no filler.

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 5-param optional query that already has an output schema, the description still covers algorithm, edge cases, return semantics, defaults, and performance tradeoff. An agent can safely invoke and interpret results without needing the structured output schema.

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?

Schema description coverage is 0%, and the Args section compensates fully: finding_id gets an example, status gets its default, file gets 'substring match', and resolve_anchors gets a detailed explanation of behavior and cost. This adds real meaning beyond the bare schema names.

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?

Opens with a specific verb and resource: 'Check if findings are stale by comparing against git history.' It also enumerates the exact file_status verdicts (current/modified/renamed/deleted/unknown), making the purpose concrete and distinct from any sibling tool.

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?

The description gives clear context for when to use it (staleness against git history, optional filters by finding_id/status/category/file) and explains the cost tradeoff of resolve_anchors. It does not explicitly name alternatives or when-not-to-use cases, so it falls just short of full routing guidance.

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

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/faxik/codebugs'

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