Skip to main content
Glama
Sign In
showntell

showntell

by rahimnathwani
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Finish walkthrough

finish_walkthrough

Close the walkthrough after its last slide. Records the end questions and returns a summary: remaining problems, each slide's start time and look (kind, layout, takeaway, icons) and what could not be checked.

Instructions

Close the walkthrough after its last slide. Records the end questions and returns a summary: remaining problems, each slide's start time and look (kind, layout, takeaway, icons) and what could not be checked. It names runs of slides that look alike, with pictures of them; revise one in each run into a different look before telling the user. With Playwright installed it first draws every slide, so the summary already reports render and layout problems (render errors, text_too_small, overflow, drawing_overlap); fix them with revise_slide. Call preview_slides only for slides it names, a drawing or diagram you want to see, or when the user asks. Then tell the user it is finished and give the link; if they want a video or a file to send, call export_walkthrough.

Input Schema

NameRequiredDescriptionDefault
handleYesHandle from start_walkthrough.
questionsNoTwo or three short follow-up questions the viewer might ask next, as a list of strings. Offered at the end of the walkthrough. Optional when the Markdown already lists them under a `.questions` heading; questions passed here replace those.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare it is not read-only, not idempotent, and not destructive, so the safety bar is lower. The description adds substantial behavioral context: it records end questions, may render slides via Playwright, returns a structured summary, flags render and layout issues, and gives post-finish instructions.

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 purpose is front-loaded in the first sentence, and most of the long paragraph earns its place by specifying follow-up routing. It is dense but appropriate for a complex closing operation, though a slight structural break would improve readability.

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?

There is no output schema, and the description explains the returned summary contents: remaining problems, slide timing and look, uncheckable items, and grouped similar-slide runs with pictures. It also covers rendering behavior and what to do after finishing, making the definition complete enough for an agent to act correctly.

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 schema already documents both handle and questions thoroughly. The description mentions end questions being recorded, but it does not add syntax or semantics beyond the schema baseline.

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: closing the walkthrough after its last slide. It distinguishes itself from siblings by assigning preview_slides, revise_slide, and export_walkthrough to specific follow-up situations.

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?

Explicitly says when to call this tool, when to call preview_slides only, when to use revise_slide, and when to use export_walkthrough. The routing is detailed enough that an agent can choose among siblings without inference.

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