Skip to main content
Glama
VictorLetirand

inkboard

by VictorLetirand
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

format_text

Formats existing board text, connector labels, or table cells by applying bold, italic, underline, strikethrough, color, or highlight to the whole text, a match, or a character range.

Instructions

Formats text already on the board, like selecting it in the application: bold, italic, underline, strike, color, highlight. Works on a shape's text, a connector's label, or one table cell (cell). Choose the part with match (first occurrence; every one with all: true) or range [start, end) (character indices of the plain text, end excluded); with neither, the whole text. clear: true removes all formatting of the part first (then the other options apply). Returns changed: the number of characters whose formatting changed. Error if match is not found.

Input Schema

NameRequiredDescriptionDefault
idYesObject id (add_shape, describe_board…).
allNoWith `match`: format every occurrence, not only the first.
boldNotrue applies bold, false removes it.
cellNo[row, column] (from 0) of the table cell to format; required for a table, invalid otherwise.
pageNoPage: number (from 1) or name. Defaults to the first.
pathNoPath of the board file (.inkboard; .inkboard.json and .tableau.json also accepted). Optional when the application is open: the tool then acts live on the displayed board (undoable with Ctrl+Z).
clearNotrue removes every formatting of the part.
colorNoText color: "#rrggbb" or "ink" sets it, null removes it.
matchNoSubstring to format (case-sensitive).
rangeNo[start, end): character indices, start included, end excluded.
italicNotrue applies italic, false removes it.
strikeNotrue applies strikethrough, false removes it.
highlightNoHighlight color behind the text: "#rrggbb" or "ink" sets it, null removes it.
underlineNotrue applies underline, false removes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.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 full burden and does well: it discloses the return value (`changed`, count of characters whose formatting changed), the error condition when `match` is missing, and the ordering semantics of `clear: true` running before the other options apply. It omits permission or live-vs-file nuances beyond what the schema already states for `path`.

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-loads the operation and targets, then flows into part selection, then return/error behavior. Dense but nearly every clause carries information; a slight trim of the parenthetical color list would tighten it further.

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?

For a 14-parameter mutation tool with no annotations and no output schema, the description supplies the return format, the failure mode, and the interaction order of options. It leaves the live-board vs file behavior to the `path` schema description, which is reasonable.

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 baseline 3, but the description adds genuine cross-parameter meaning the schema cannot: `match` is first-occurrence unless `all: true`, `range` is half-open over plain-text indices, the default when neither is given, and that `clear` executes before other options. `cell` applicability is also clarified (valid for a table, invalid otherwise is in schema).

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 plus the exact target types: text on a shape, a connector's label, or a single table cell. It draws a clear line against siblings like update_object by describing the operation as the application's own text selection (bold, italic, underline, strike, color, highlight).

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?

Gives concrete selection rules: choose the part with `match` (first occurrence, or every one with `all: true`) or `range` [start, end), and with neither the whole text is formatted. It does not say when to prefer this tool over update_object or add_shape, but the targeting guidance is strong.

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