BytesJev PlanningChecker

Overview Schema Source Related Servers Discussions Admin

Planning Checker

PlanningChecker

Read-onlyIdempotent

Check proposed plan items for overengineering before editing files: submit your request, plan, and repo conventions to get per-item keep, simplify, or review advice.

Instructions

Advisory check for overengineering. Call it once after you have a plan and before you edit any file.

Send the user's ORIGINAL request verbatim (never reconstruct it), every meaningful proposed addition as its own plan item with your honest rationale, and the repository conventions or constraints that bear on those items. Do not send secrets, .env contents, or unrelated source: the payload is transmitted to the Jev API.

Each item comes back with a necessity_score (Jev's support for the specific question "is this needed by the request, a stated constraint, or correctness/security"; not a verified probability), a recommendation (keep / simplify / review), a reason that cites your submitted text, and an uncertain flag. "simplify" is only given when the other plan items alone would satisfy the request. "review" means the evidence is mixed or missing: decide yourself and name the concrete need if you keep the item. On status "unavailable" proceed with your plan as normal.

Limits: 25 items, 4000 chars of request, 8000 chars of context; truncation is reported in limitations.

Input Schema

TableJSON Schema

Name	Required	Description
`plan_items`	Yes	Each meaningful proposed addition with a stable id and your rationale.
`repo_context`	No	Existing conventions, utilities, or constraints relevant to the plan items. Facts you observed in the repository, not guesses.
`user_request`	Yes	The user's original request, verbatim.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`errors`	No
`status`	Yes
`results`	Yes
`limitations`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 27, 2026

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description goes further with genuinely additive, non-obvious behavior: the payload is sent to the Jev API (external transmission), truncation is reported in limitations, and the meanings of the 'unavailable' status and 'simplify' vs 'review' outputs are disclosed. That is unusually rich for one paragraph, but it stops short of describing latency or rate-limit behavior, keeping it below the top of the range.

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?

Front-loads the purpose and the trigger, then the payload rules, then output semantics, then limits. Every sentence carries information, but the output-semantics sentence is long and reads as a single dense block rather than a scannable list, so it is slightly heavier than ideal.

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?

Despite an output schema being present, the definition still explains what each returned field means and how to act on 'review' and 'unavailable', and it documents the input limits (25 items, 4000/8000 chars) with truncation reporting. Nothing an agent needs to invoke this 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 coverage is 100%, so the baseline is 3, but the description adds real semantics the schema cannot: send the request verbatim, never reconstruct it; decompose each meaningful addition into its own item with an honest rationale; and a hard exclusion list (secrets, .env, unrelated source). These are usage constraints on the three parameters, not restatements.

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?

States a specific verb and resource ('advisory check for overengineering') and pins the exact moment to call it: once, after planning, before editing files. An agent knows precisely what this tool is and is not (a verifier, not a planner or editor).

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

Usage Guidelines5/5

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

Explicit timing ('once after you have a plan and before you edit any file') and an explicit failure-mode instruction ('On status "unavailable" proceed with your plan as normal'). No siblings exist, so no alternative routing is needed, and the when-not condition is still covered.

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

PlanningCheckerA