Skip to main content
Glama

fci-mcp

by ai.fluxink

fluxink-mcp-chatgpt-show-handwriting-canvas

Read-only

Open the FluxInk handwriting recognition canvas. The user draws freehand strokes with a stylus, finger, or mouse. The strokes are converted by one of two model families: general recognition for handwriting, math, and chemical formulas, or structure recognition for molecular structures.

Use this when the user asks to handwrite, draw, sketch, ink, scribble, or scrawl something. Use this when the user wants to draw a math equation, chemical formula, or molecular structure rather than type it. Use this when the user asks for a canvas, drawing pad, handwriting input box, or whiteboard. Use this when the user wants to convert stylus or finger drawings into recognized text or markup.

Do NOT use this when the user types a question, equation, or formula in chat and just wants an answer. Do NOT use this when the user uploads or references an existing image of handwriting (call recognize_image instead). Do NOT use this when the user wants a formatted document, study sheet, or layout PDF (call create_layout instead). Do NOT use this when the user wants text rendered in a personal handwriting style (call show_style_canvas instead). Do NOT use this for conversational or informational requests that need no ink input.

Do NOT re-open if a FluxInk handwriting canvas is already visible from any earlier turn. Instead instruct the user to keep drawing on the existing canvas. Only set force_new=true when the user explicitly asks for a brand new, fresh, or blank canvas.

Always pass the original chat message in the prompt parameter so context is preserved after recognition. After calling, write a single short acknowledgement and do NOT describe the canvas UI.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoRecognition family for the canvas. Use general for text, math, and chemical formulas; use structure only for molecular structures.general
promptNoThe original chat message that triggered the canvas. Passed through to the follow-up message after recognition.
languageNoOptional language hint for text mode. Omit to use the mixed-language model default.
force_newNoSet true ONLY when the user explicitly asks for a brand-new canvas. Otherwise leave false so a previously opened canvas is reused.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
reuseNo
promptYes
messageYes

TDQS

A4.7/5.0
Behavior4/5

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

While annotations already include readOnlyHint=true, the description adds context about recognition families, canvas reuse behavior, and the prompt passthrough. No contradiction with annotations, but more detail on side effects (e.g., whether previous strokes are cleared) could be beneficial.

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 description is well-structured and front-loaded with the core purpose. It is longer than minimal but every sentence adds value. A slight reduction could be possible without losing clarity.

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?

Given the presence of an output schema and comprehensive annotations, the description covers all needed aspects: purpose, usage boundaries, parameter details, and behavioral rules. No obvious gaps remain.

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?

With 100% schema coverage, the description adds significant meaning beyond the schema: explains mode families, when to use force_new, the role of prompt, and language as optional hint. Each parameter is clearly contextualized.

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 clearly states the tool opens a FluxInk handwriting recognition canvas and explains its functionality. It explicitly distinguishes from sibling tools like recognize_image, create_layout, and show_style_canvas by giving specific use cases.

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?

The description provides explicit when-to-use and when-not-to-use instructions, including alternatives (e.g., use recognize_image for existing images). It also covers edge cases like not re-opening an existing canvas and when to set force_new.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All fci-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: layout generation, handwriting canvas, style canvas, image text recognition, and two internal endpoints. The descriptions are highly detailed with explicit 'Do NOT use' instructions, making it easy for an agent to select correctly.

Naming Consistency4/5

Tool names follow a consistent verb-noun pattern (create, recognize, show, synthesize) with hyphens. Minor inconsistency: two 'recognize' tools could cause confusion, but one is clearly marked as internal. Overall, the naming is predictable and readable.

Tool Count5/5

With 6 tools, the server is well-scoped for its domain of document layout, handwriting input, OCR, and style generation. Each tool earns its place, and the count is neither too small nor excessive.

Completeness4/5

The tool set covers the main workflows: layout creation, handwriting capture/recognition, image OCR, and personal handwriting style synthesis. Minor gaps like lack of an edit tool for layouts are understandable given the domain; agents can work around them.

Resources