Skip to main content
Glama
Sign In
mimry

mimry

by jbacalso24
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mimry_impact

Trace what a symbol or file change touches: callers, importers, referencing files, and tests to run, following call depth and optionally diffing the working tree against HEAD.

Instructions

What a change touches: callers, importers, referencing files and tests to run.

target is a symbol name (file picks one when several share it, and line picks by the line it starts on or spans) or a repo-relative file path. changed=True uses the working tree against HEAD instead. depth is 1 to 5, how many calls back to follow.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mimry_impact"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNo
lineNo
rootNo
depthNo
targetNo
changedNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose mode semantics (working tree vs HEAD) and depth meaning, which is real behavioral value. Gaps remain: nothing about ambiguity resolution failures, unresolved targets, cost/latency of deeper recursion, or that the operation is read-only and non-mutating.

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?

The outcome is front-loaded in the first line, then parameters are explained in short sentences with no filler. The parenthetical about file/line disambiguation is dense but earns its space; a slightly tighter phrasing would improve it further.

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?

An output schema exists, so return values need not be explained, and the description covers target resolution, mode selection, and depth. The undocumented 'root' parameter and unstated behavior on ambiguous or unresolvable targets are the remaining gaps for a six-parameter analysis tool.

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 description coverage is 0%, so the description must compensate, and it does for five of six parameters: target forms, file/line disambiguation rules, changed mode, and the 1–5 depth range. Only 'root' is left completely undefined, which costs a point.

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 opening clause names a concrete analysis outcome (callers, importers, referencing files, tests to run) for a change, which is specific and actionable. It does not, however, contrast itself with siblings like mimry_find, mimry_why or mimry_related, so an agent must infer which sibling to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It describes the two operating modes clearly (symbol/file target vs changed=True against HEAD) and the depth bound, implying when each applies. There is no explicit when-not-to-use guidance or named alternative sibling, leaving the choice between impact and related/why tools to inference.

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

Deploy Server

Other Tools