Loading ToolBench
MCP server exposing the skill's external visual review as a stdio MCP server for rendering and reviewing presentation slides
This MCP server has severe definition quality issues. Descriptions are minimal (review_slides: 57 chars, review_deck: 52 chars) and lack critical context about prerequisites, return structure, parameters, or error recovery. No parameter descriptions exist because parameters are absent from schemas. Tool names lack clarity about what 'review' means in context, are they analyzing content, rendering visuals, or generating feedback? The server exposes no tool output schemas, making it impossible for LLMs to know what data to expect or how to chain downstream operations. There is no evidence of structured output specification, pagination, or error handling patterns. This reads as a minimal skill wrapper rather than a production-grade MCP tool interface.
Render and review the exported answer.pptx contact sheets.
Render and review every HTML slide with the configured visual model.
Both tools have empty input schemas ({}). This prevents LLMs from understanding what, if anything, these tools accept as input.
No output schemas documented. LLMs cannot know what fields these tools return, breaking downstream tool chaining and forcing manual extraction.
Descriptions are extremely brief (review_slides: 'Render and review every HTML slide with the configured visual model.' = 57 chars; review_deck: 'Render and review the exported answer.pptx contact sheets.' = 52 chars). They lack actionable context: What are the prerequisites? What does 'render and review' mean technically? When should the LLM call each? What does the response contain?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 65 | - | v1 |
Tool names 'review_slides' and 'review_deck' are vague. 'Review' could mean inspect, analyze, grade, compare, or render. No action verb clarity. Compare to: 'render_slide_html_to_image' or 'analyze_slides_with_vision_model', much clearer intent.
No error handling documentation. What happens if slides fail to render? If the visual model is unavailable? If workspace files are missing? LLMs have no recovery guidance.
No permissions or scope declaration. These tools interact with file I/O and external vision APIs, but no security boundary is stated (read-only is noted in Risk field, but not in the description for LLMs).