Skip to main content
Glama
michal-niedzwiedzki

visimark

by michal-niedzwiedzki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}
prompts
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
visimark_refA

Look up VisiMark's builtin functions: signature, arity, precision, errors and examples. Give name to look it up, or omit name for the whole reference. Reads no file.

visimark_checkA

Verify that every computed number in a Markdown document still agrees with the formula that produced it, and report what does not. Findings are a successful result, not an error. A document given as content has no directory, so imports and generated artifacts cannot be verified; skipped names the ones that were not checked.

visimark_explainA

Describe what a document declares: its sheets, input columns, computed rules, anchored scalars, derived precision and imports. Give sheet to narrow it.

visimark_evalA

Evaluate a document and return its values, its assertions and its charts. Give get to select a single named value. Give scenarioPath or scenarioContent to substitute parameters and see what moves — a draft scenario against a draft document, with no temp file. A false assertion is a successful result reporting problems.

visimark_inferA

Derive the formulas an existing Markdown table already obeys, and propose them as vmark rules. Run this before hand-authoring rules for a document that already has its numbers. Returns proposals only and never writes; visimark_infer_apply writes them.

visimark_fmtA

Plan the edits that would bring a document's stored numbers back into agreement with its formulas, and name the generated artifacts it would write. Nothing is written: pass the returned plan to visimark_fmt_apply to land it. It repairs stale computed values, anchors and generated artifacts, and nothing else — never prose, never a column with no rule, never any other finding class. A document given as content has no directory, so imports and generated artifacts cannot be verified; skipped names the ones that were not checked.

visimark_fmt_applyA

Land the plan visimark_fmt returned: splice the document's computed cells and anchors, and write the generated artifacts it named. Refused if the document changed since the plan was computed, and refused entirely unless the operator started the server with --allow-write and the host declared a root.

visimark_infer_applyA

Insert the vmark rules visimark_infer proposed. Pass the plan you were given, with any proposal you rejected removed. Refused if the document changed since the plan was computed, and refused entirely unless the operator started the server with --allow-write and the host declared a root.

Prompts

Interactive templates invoked by user choice

NameDescription
visimark/take-overTake over a Markdown document that already has its numbers. Runs `infer` first, because hand-authoring rules for a document that already computed its values is how you end up encoding the wrong ones.
visimark/authorWrite a new VisiMark document in the order that works: table, then `vmark` block, then anchors, then prose, then `fmt`. Prose written before the rules exist is prose full of numbers you typed yourself.

Resources

Contextual data attached and managed by the client

NameDescription
skillHow to author and edit a VisiMark document: the orderings to follow, the traps to avoid, and why a green check is evidence of agreement rather than of derivation. Read this before writing a document, not after.
cli-referenceEvery command, option, exit code and finding code, with what each one means. The normative source for what a field in a tool result says.
function-referenceThe builtins: signature, parameters, return type, precision, errors and worked examples. Generated from the engine's own registry, and every example is executed in CI.
example-invoiceA finished VisiMark document: tables, rules, anchored scalars, assertions and prose that agree with each other.
example-driftThe worked invoice with a single input edited and nothing derived from it updated — what `visimark_check` is for, shown rather than described.
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 8 tools

Disambiguation5/5

Each tool has a clearly distinct role: ref (lookup builtins), explain (describe declarations), eval (compute values), check (verify agreement), infer (propose rules), fmt (plan repairs), and their _apply counterparts. The plan-then-apply split is explicit and the read-only analyzers (check vs eval vs explain) are differentiated by their descriptions.

Naming Consistency4/5

All tools use a consistent visimark_ snake_case prefix with verb-based names, and the _apply suffix reliably marks write actions. Minor deviation: 'ref' and 'fmt' are abbreviations while others are full verbs, but the pattern remains predictable.

Tool Count5/5

Eight tools is well-scoped for a document-analysis/formula-verification server, with each tool earning its place. Read/plan/apply responsibilities are cleanly separated without redundancy.

Completeness5/5

The surface covers the full lifecycle: reference lookup, document description, evaluation, verification, inference, formatting, and the apply operations to land each plan, all with write-safety gating. No obvious gaps for the stated domain.

Resources