Skip to main content
Glama
Sign In
Review Helper

Review Helper

by antoinebou12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Update feature review plan

propose_review_plan
Idempotent

Generate a review plan to replace local feature sections with existing paths and evidence-backed relationships, without writing provider changes.

Instructions

Replace local feature sections using existing paths and evidenced relationships. No provider writes.

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": {
      "review_id": "<review_id>",
      "expected_head": "<expected_head>",
      "plan": "<plan>"
    },
    "name": "propose_review_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
planYesComplete feature sections and evidenced file relationships.
review_idYesReview snapshot ID.
expected_headYesHead commit SHA from the current snapshot.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds real value beyond that by disclosing replacement semantics (existing local sections are overwritten) and by explicitly ruling out provider writes, which is not encoded in any annotation. However, it omits the concurrency implication of expected_head and whether omitted sections are deleted, so the transparency is partial.

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?

Two short sentences, front-loaded with the action, with zero filler or repetition. It is efficient, bordering on terse enough that some clarifying clauses were cut rather than trimmed.

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

Completeness3/5

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

The schema fully defines the nested ReviewPlan, and annotations cover safety, so much of the burden is off the description. The critical unresolved question for an agent calling this with an expected_head token is whether "replace" means full replacement (deleting absent sections) or merge by section id, and the description does not resolve it.

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 the baseline is 3 and the schema carries the parameter documentation. The description adds only a light gloss: "existing paths" gestures at the file/hunk paths and "evidenced relationships" hints that Relationship.evidence is mandatory, but it adds no detail on review_id or expected_head semantics.

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?

"Replace local feature sections" gives a concrete verb (replace) and resource (feature sections), and "No provider writes" scopes it away from provider-facing siblings. It is clear what the tool operates on, though it never names the review plan/snapshot object it mutates, which slightly weakens differentiation from siblings like read_section.

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?

"Using existing paths and evidenced relationships" implies a precondition (paths must already exist, relationships need evidence) but never states when to choose this over alternatives or when not to call it. Usage is inferred rather than stated, which is the definition of minimum-viable guidance.

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