Skip to main content
Glama
Sign In
toolmenu

toolmenu

by niksa90
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

review_baseline

Read-only

Compare a candidate menu file with the committed baseline before overwriting it: get a verdict (unchanged, safe, breaking, review), caller-breaking changes, and added, cleared, or worsened findings.

Instructions

Say whether a new menu file should replace the baseline: one verdict (unchanged, safe, breaking-released, breaking, review), what breaks callers, and which findings the new menu adds, clears or makes worse. Use it before overwriting a committed menu.json. Reads the two files only and starts no server.

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": {
      "baseline": "<baseline>",
      "candidate": "<candidate>"
    },
    "name": "review_baseline"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdNoFolder to run from: where the server starts, toolmenu.config.json is read and relative paths resolve. Default: where toolmenu mcp runs.
releaseNoThe release versions, so breaking changes pass when the bump allows them: "1.4.0..2.0.0".
baselineYesThe menu file to replace, e.g. the committed menu.json.
candidateYesThe new menu file, e.g. new-menu.json from snapshot_menu save_as.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.27.1

TDQS

A4/5.0
Behavior4/5

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

Beyond readOnlyHint=true and openWorldHint=false, the description adds real behavioral context: it reads only the two files and starts no server, which matters for a tool whose other siblings may launch one. It also discloses the return content (verdict taxonomy plus findings delta), though it does not cover failure modes like a missing or malformed menu file.

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?

Two sentences, front-loaded with the verdict outcome, then the operational constraint and intended use. No filler, no restatement of the title.

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?

With no output schema, the description carries the burden of describing returns and does so by enumerating the verdict options and the findings delta. Combined with fully documented parameters and safety annotations, an agent has what it needs to call it; only error/edge behavior is unstated.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (cwd, release, baseline, candidate) are already documented with examples and defaults. The description adds only indirect meaning, hinting that the release parameter governs when breaking changes pass via the "breaking-released" verdict, but adds no syntax or format detail beyond the schema.

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 names a specific resource (a new menu file vs. the committed baseline) and states the exact output shape: one verdict from unchanged/safe/breaking-released/breaking/review, what breaks callers, and findings added/cleared/worsened. It is clearly distinct from a plain diff, but it never names the sibling diff_menus, leaving sibling routing 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?

"Use it before overwriting a committed menu.json" gives an explicit precondition that selects this tool. It stops short of naming when-not-to-use or pointing at diff_menus/snapshot_menu as alternatives, so the guidance is clear but not exhaustive.

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