mimry

by jbacalso24

Overview Schema Source Related Servers Discussions Admin

Python

Local

mimry_preflight

Run a readiness check and gather task context from local repository memory, matching CLI behavior before coding.

Instructions

Fast readiness check and task context, matching CLI preflight.

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": {
      "query": "<query>"
    },
    "name": "mimry_preflight"
  }
}

Input Schema

Name	Required	Description	Default
`root`	No
`query`	Yes
`semantic`	No
`force_refresh`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.1Oct 17, 2026
- addedInput schema / properties / semantic
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
First observedv0.2.1Oct 2, 2026

TDQS

D1.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only hints that the tool is 'fast' and involves a 'readiness check'. It does not say whether the operation is read-only, whether it mutates state, what permissions are needed, or how force_refresh and semantic affect behavior. This leaves significant gaps for a tool with four parameters and no structured hints.

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

Conciseness2/5

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

The single sentence is short but under-specified rather than appropriately concise. The second clause 'matching CLI preflight' does not earn its place because it adds no actionable information, and the overall size is inadequate for a tool with four parameters and no schema documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a required query parameter, three optional parameters with zero schema descriptions, and no annotations, the description is completely inadequate. While an output schema exists and need not be explained, the description leaves the agent without any information about parameter meaning, required permissions, side effects, or usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/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 for four undocumented parameters, yet it provides no meaning for root, query, semantic, or force_refresh. The phrase 'task context' vaguely gestures at query but does not clarify format or intent, leaving the agent unable to use any parameter correctly without experimentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names two vague functions ('readiness check' and 'task context') but does not specify a concrete verb+resource or distinguish this tool from its many siblings like mimry_status or mimry_find. 'Matching CLI preflight' is an opaque reference that provides no additional clarity for an agent that has not used the CLI.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as mimry_find, mimry_status, or mimry_why. The description neither states prerequisites nor excludes any scenarios, leaving the agent to guess at the tool's role.

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

Deploy Server