resolve_sprint_item_pointers
[SUPPORT] 2976e168 — resolve EVERY generic pointer on a sprint item to its concrete location, dispatching by selector.type. A range target returns its location as-is; symbol resolves the qualified_name against the SAME live three-rung chain prospect_symbol uses (graph → Serena → semantic, 653579c...
This record as markdown: /tools/io-github-ajc3xc-meridian/resolve-sprint-item-pointers.md
What resolve_sprint_item_pointers does on Meridian
AI agents use resolve_sprint_item_pointers to create or update resources in Meridian, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Meridian environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
root_dir | string | — | Optional absolute path to the source tree root, passed through to the symbol resolver's search_code_semantic fallback rung (same as prospect_symbol's root_dir) |
project_id | string | — | |
project_name | string | — | Project name — an alternative to project_id; resolved to the id internally. project_id wins if both are given. |
sprint_item_id | string | Yes | The sprint item whose pointers to resolve. |
Parameters from the server's own tool schema.
Why resolve_sprint_item_pointers is rated Medium
An AI agent can call resolve_sprint_item_pointers faster than any human can review: one bad instruction and it creates or modifies resources in Meridian by the hundred, each call as confident as the last.
Risk signalsBulk/mass operation — affects multiple targets · Admin/system-level operation
Attacks that exploit this kind of access
The rule that runs resolve_sprint_item_pointers safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Meridian, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For resolve_sprint_item_pointers, this is the rule to start with:
resolve_sprint_item_pointers stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Meridian, apply this rule, and every resolve_sprint_item_pointers call is checked against it from then on.
Questions about resolve_sprint_item_pointers
[SUPPORT] 2976e168 — resolve EVERY generic pointer on a sprint item to its concrete location, dispatching by selector.type. A range target returns its location as-is; symbol resolves the qualified_name against the SAME live three-rung chain prospect_symbol uses (graph → Serena → semantic, 653579c5) when this session has an active code tunnel, falling back to the cached code-graph snapshot when it doesn't; node_id looks the element up in the doc-structure store; zotero_key resolves via Zotero's local API; text_quote re-fetches the URL (or docx paragraph text) and flags content drift; finding_id looks up a save_finding artifact note. 62640241 — directory walks the local root and returns a manifest + manifest_hash; git shells out to git rev-parse against a local clone to check ref/commit reachability against HEAD; artifact hashes a local manifest file for its current fingerprint; remote_fs has no core-local default (requires a tunnel-backed resolver — reported explicitly unresolved without one). Every one of these five ALSO gets a recomputed freshness_state (current/stale/unknown/unavailable/ambiguous) on its resolved target, comparing the target's declared freshness proof (if any) against what resolution finds right now. A subSelector narrows the outer resolution ('these lines, within this function'). Every dispatch is best-effort: an unresolvable target yields {resolved:false, reason} instead of an error, and the pass NEVER fails. Returns {pointers:[{id, source_type, label, targets:[<resolved-target>]}]}. Requires no network for range/symbol/node_id/directory/git(local)/artifact(local); zotero_key needs Zotero running locally and text_quote needs live web access (else those targets are just unresolved). It is categorised as a Write tool in the Meridian MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
resolve_sprint_item_pointers accepts 4 parameters: root_dir, project_id, project_name, sprint_item_id. Required: sprint_item_id. The full parameter table on this page comes from the server's own tool schema.
Register the Meridian MCP server in PolicyLayer and add a rule for resolve_sprint_item_pointers: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Meridian. Nothing to install.
resolve_sprint_item_pointers is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the resolve_sprint_item_pointers rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for resolve_sprint_item_pointers. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
resolve_sprint_item_pointers is provided by the Meridian MCP server (@meridianmcp/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Meridian, and thousands of servers like it.
This server
Across the catalogue