Skip to main content
Glama

anchor_resolve

Resolve code finding anchors to current HEAD lines, returning statuses for moved, lost, or ambiguous locations to keep tracking accurate.

Instructions

Resolve stored location anchors to their current lines on HEAD.

Each anchored finding gets a record: status (current / moved / moved_file / lost / ambiguous / unknown), the coordinate, the channel that produced it ("git" for reverse blame, "content" for the secondary text channel), a reason token when there is no answer, and survived as "/" when part of a span outlived the rest.

moved_file is a status of its own, not moved with a different path: the code left the file the finding names, and a consumer must see that rather than receive a line number in a file it never asked about.

THE SUMMARY'S DENOMINATOR IS anchored, NOT total. anchored counts the rows that CARRY an anchor (a persisted refusal and the tombstone included); rows filed before anchors existed carry none and are counted in without_anchor instead. So a moved_file share is summary["moved_file"] / anchored; computing it against total is a share of a population the number does not describe.

Args:

  • finding_id: Resolve one finding instead of a population

  • status: Status filter; "all" widens to every status (default: open)

  • category: Restrict to one category

  • file: Restrict to one file (the finding's file column)

  • project_dir: The repository the anchors resolve against. Omitting it reports no_root rather than reading whatever tree the server process happens to stand in — a long-lived server's cwd has nothing to do with the tracker a call is about

  • limit: Maximum findings examined (default 10000). 0 means NO findings are examined; a negative value is an error (it used to mean "no limit").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNo
limitNo
statusNoopen
categoryNo
finding_idNo
project_dirNo

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.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers extensive behavioral detail: each record's fields and statuses, the special meaning of moved_file, the summary denominator being anchored rather than total, and the unexpected behaviors of project_dir and limit. These are exactly the kinds of traps an agent needs to know about.

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?

The description is long but every section earns its place: core purpose, output record format, status semantics, a critical denominator warning, then parameter explanations. It is front-loaded with the most important information and contains no filler or tautology.

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 complexity of the tool and the presence of an output schema, the description is complete. It explains the return record structure, all statuses, the denominator semantics, and parameter edge cases. Nothing an agent needs to invoke the tool correctly is missing.

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%, so the description must compensate, and it does thoroughly. Every parameter receives a purpose explanation, and the trickiest ones get edge-case warnings: project_dir's no_root behavior, limit's 0 meaning no findings and negative being an error, and the distinction between open and all for status.

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 states a specific verb-resource pair: 'Resolve stored location anchors to their current lines on HEAD.' This clearly identifies what the tool does. However, it does not explicitly distinguish itself from the sibling tool anchor_recapture, so while the purpose is unambiguous, sibling differentiation is left to inference.

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 provides clear context on when to use the tool and how to narrow scope: finding_id for a single finding, status filters, category, file, project_dir, and limit. It includes notable guidance such as omitting project_dir yielding no_root rather than using the server's cwd. However, it does not explicitly mention alternatives or when-not-to-use it compared to related siblings like anchor_recapture.

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