Skip to main content
Glama
Sign In
AInotate

AInotate

by dontpayfull
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

make_guide

Create step-by-step guides from annotated images, exporting Markdown, HTML, or PDF with one image and text per step. Preview drafts first, then save final files to the output folder.

Instructions

Build a step-by-step guide from annotated images: Markdown, HTML and/or PDF, one image and text per step, every image at its own size. Use it after annotate when the user wants a how-to or documentation; for a single image just deliver the annotate output. Draft by default (temp folder): check the preview, then call again with draft=false to save to the output folder. PDF uses Playwright when available, else a Pillow page per step. Writes files only. Returns the file path per format, the PDF backend, warnings and a preview of the first step.

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": {
      "steps": "<steps>"
    },
    "name": "make_guide"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoBase file name in the output folder, no extension. Empty = tool default.
draftNotrue (default): write to a temp folder so you can check the preview first. false: save to the output folder (~/Pictures/AInotate unless configured) and the backup folder.
stepsYesGuide steps in order: [{"image": path, "text": "...", "title"?: "...", "alt"?: "..."}].
titleNoGuide title.
formatsNoAny of "md", "html", "pdf". Default md + html.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • addedInput schema / properties / draft / description
      Added value: +"true (default): write to a temp folder so you can check the preview first. false: save to the output folder (~/Pictures/AInotate unless configured) and the backup folder."
    • addedInput schema / properties / formats / description
      Added value: +"Any of \"md\", \"html\", \"pdf\". Default md + html."
    • addedInput schema / properties / name / description
      Added value: +"Base file name in the output folder, no extension. Empty = tool default."
    • addedInput schema / properties / steps / description
      Added value: +"Guide steps in order: [{\"image\": path, \"text\": \"...\", \"title\"?: \"...\", \"alt\"?: \"...\"}]."
    • addedInput schema / properties / title / description
      Added value: +"Guide title."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare non-readOnly/non-destructive, but the description adds substantial context beyond them: draft writes to a temp folder, draft=false writes to the output folder and a backup folder, PDF rendering falls back from Playwright to a Pillow page per step, and it 'writes files only'. It also enumerates return contents (file path per format, PDF backend, warnings, first-step preview).

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?

Front-loaded with purpose, then usage, workflow, backend behavior, and return shape — every sentence carries information. It is dense and clause-heavy (long run-on sentences), which costs a little readability, but there is no filler.

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?

With no output schema, the description compensates by describing the return payload (paths per format, PDF backend, warnings, first-step preview). Combined with the draft/save workflow and the format defaults, an agent has everything needed to call it correctly in one or two turns.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents name, draft, steps, title and formats; baseline would be 3. The description still adds semantics not in the schema, notably 'one image and text per step' and 'every image at its own size', and frames draft as a review-then-commit workflow.

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+resource ('Build a step-by-step guide from annotated images') plus the output formats (Markdown, HTML, PDF) and the step structure. It also explicitly differentiates from the sibling 'annotate' tool, so an agent can route correctly without opening schemas.

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?

Gives explicit when-to-use ('after annotate when the user wants a how-to or documentation') and when-not ('for a single image just deliver the annotate output'), naming the alternative. The draft workflow ('check the preview, then call again with draft=false') is spelled out as an operational sequence.

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