Skip to main content
Glama
Sign In
doc-review

doc-review

by MichaelEight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

review_style

Set, list, or clear per-workspace display rules that color literal or regex matches and attach hover or inline notes without editing files.

Instructions

Set, list or clear display rules: colouring and notes that change how files are SHOWN in the UI and never touch what they contain. A rule matches a literal or a regular expression in the files its scope globs select, then paints it (colour, background, bold, italic, underline, strike, dim), attaches a note to it (on hover or inline), or both. Use it when the user asks for something like "colour this nick blue", "give the text in <> a grey background", "dim the timestamps" or "on hover show how long since the previous line". Rules are per workspace and persist.

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": "review_style"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNoDefault set.
idsNoclear: the rules to remove. Omit to remove all of them.
fileNolist: show only the rules that apply to this file.
rootNoAbsolute path of the workspace folder. Optional when only one workspace is open.
rulesNoset: the rules to add or update.
replaceNoset: drop every existing rule first (default false, which adds and updates).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that rules persist per workspace, that opts default to set, that styling targets only the reading view, and that the annotate note is decoration never written to the file and cannot be selected or copied. Remaining gaps are operational, e.g. what happens with an invalid regex or a clear with unknown ids.

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 most decision-relevant fact (display-only, never touches content) is front-loaded before the mechanics, and the example phrases earn their place by showing the request patterns the tool should catch. A few mechanics sentences could be tightened, but nothing reads as filler.

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?

For a 6-parameter tool with nested rule objects, no annotations and no output schema, the description supplies the mental model (match, then paint or annotate or both) that the schema alone would not convey. It does not say what list returns or what clear reports, which an agent managing rules might want.

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; the nested match, scope, style and annotate properties already document themselves thoroughly. The description adds the overall op vocabulary and the pattern of what a rule is, but no parameter-level detail beyond the schema.

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?

Opens with a specific verb set (set, list, clear) plus the resource (display rules) and immediately states the key scope boundary: it changes how files are SHOWN in the UI and never touches what they contain. That distinguishes it cleanly from siblings like review_define_tag, which operate on data rather than presentation.

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?

Gives concrete, natural-language triggers ("colour this nick blue", "dim the timestamps", "on hover show how long since the previous line") plus a few more in the schema, so an agent can pattern-match a user request to this tool. It stops short of naming an alternative or stating when-not to use it, so the boundary against review_define_tag or review_comment must be inferred.

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