Skip to main content
Glama
Sign In
CodeTour

CodeTour

by benstaniford
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

show_step

Guides viewers through a pull request by selecting a file, animating its diff, scrolling to relevant lines, and speaking the narration aloud to pace the tour.

Instructions

Show one tour step: selects file in the file tree, animates its diff into view, scrolls to line_start..line_end (line numbers on the side version, as returned by get_pr_info/get_file_diff), and pulses a highlight ("highlight") or dims everything else ("spotlight"). The narration appears as a caption and is spoken aloud; the call BLOCKS until speech completes, so call show_step sequentially to pace the tour. Omit line_start/line_end to frame the whole file. Out-of-range lines are snapped to the nearest hunk and reported in warnings.

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": {
      "file": "<file>",
      "narration": "<narration>"
    },
    "name": "show_step"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileYes
sideNonew
styleNohighlight
line_endNo
narrationYes
line_startNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full burden and it does so excellently. It discloses all behavioral traits: selecting in the file tree, animating diff, scrolling, pulsing/dimming, displaying and speaking narration, blocking until speech ends, snapping out-of-range lines to the nearest hunk, and reporting warnings. This is comprehensive and contradicts nothing.

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?

The description is dense but every sentence adds value. It front-loads the core action, then layers behavioral details (blocking, sequential), optional parameter behavior, and edge cases. No fluff or repetition; it is efficiently structured.

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?

For a 6-parameter tool with no annotations and no output schema, the description covers the action, parameter semantics, edge cases (snapping, warnings), and usage constraints (blocking, sequential). It does not explicitly mention prerequisites like an active tour or the return value, but these are implied by the tour context and the mention of warnings, making it sufficiently complete for correct invocation.

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 0%, so the description must explain each parameter, and it does: file (selects in tree), side (line numbers on that version), style (highlight vs spotlight), line_start/line_end (scroll range, omit for whole file, out-of-range snapping), narration (caption + speech). This fully compensates for the lack of schema descriptions.

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?

The description states a specific verb ('show') and resource ('one tour step'), then details the exact sequence of actions: selecting a file, animating its diff, scrolling to a line range, and applying a highlight or spotlight. It clearly distinguishes itself from siblings like start_tour, show_overview, and end_tour by describing the step-level behavior within a tour.

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?

The description gives clear usage context: call sequentially to pace the tour because the call blocks until speech completes, and omit line_start/line_end to frame the whole file. It does not explicitly contrast with alternatives, but the context of being a step in a tour and the mention of blocking sequential behavior imply when it should be used.

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