Skip to main content
Glama
Sign In
ppt-generator

ppt-generator

by haandol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ingest_visual_qa_fix

Validate and apply client-generated visual QA fixes to a slide after preparation, then save the patch and re-render HTML to restore missing images or slide types for verification.

Instructions

Ingests the client-generated fix: validate, save, re-render HTML.

Call AFTER prepare_visual_qa_fix. Restores images/slide_type the LLM can't produce. Re-run capture → analysis on this slide to verify (up to max_iterations).

Args: project_id: Target project ID (required). slide_index: 1-based slide position. fix_json: The visual patch JSON generated by the client. fix_context: Opaque context returned by prepare_visual_qa_fix.

Returns: JSON with status ("fixed" | "unfixed" | "unresolved"), slide_html_path.

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": {
      "project_id": "<project_id>",
      "slide_index": "<slide_index>",
      "fix_json": "<fix_json>",
      "fix_context": "<fix_context>"
    },
    "name": "ingest_visual_qa_fix"
  }
}

Input Schema

NameRequiredDescriptionDefault
fix_jsonYes
project_idYes
fix_contextYes
slide_indexYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.2
    • addedInput schema / properties / fix_context
      Added value: +{
+  "title": "Fix Context",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "project_id",
-  "slide_index",
-  "fix_json"
-]New value: +[
+  "project_id",
+  "slide_index",
+  "fix_json",
+  "fix_context"
+]
  2. First observedv0.7.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does reasonably well: it discloses that this is a write/mutation (save, re-render HTML), that it restores images/slide_type, and that it triggers a bounded verification loop up to max_iterations. It doesn't address reversibility, permissions, or failure handling, but the core behavioral shape is disclosed.

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 and sequencing are front-loaded in the first two lines, with Args/Returns cleanly separated. It is tight, though the Returns block partly duplicates the existing output schema.

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?

An output schema exists, so the Returns note is supplementary; the description plus Args give an agent enough to call it correctly. The main residual gap is the internal structure of fix_json, which matters most for a client-generated patch.

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 0%, but the Args block compensates well: 'slide_index: 1-based slide position' and 'fix_context: Opaque context returned by prepare_visual_qa_fix' add real meaning beyond bare types. fix_json is described only as 'visual patch JSON generated by the client,' leaving its structure under-specified.

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 specific verbs and a resource: 'Ingests the client-generated fix: validate, save, re-render HTML.' It clearly distinguishes this tool from the prepare_* siblings by naming prepare_visual_qa_fix as the predecessor, so an agent knows this is the consume/apply half of the pipeline.

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?

'Call AFTER prepare_visual_qa_fix' gives explicit sequencing, and 'Re-run capture → analysis on this slide to verify (up to max_iterations)' describes the follow-on flow. It doesn't state when NOT to call it or an alternative, but the prerequisite and verification loop are clearly stated.

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