Skip to main content
Glama
Sign In
mermaidonline-mcp

mermaidonline-mcp

by j-river
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Encode Mermaid share state

encode_mermaid_share
Read-onlyIdempotent

Encodes Mermaid source and optional config into a reversible pako token for sharing, with an option to build a share URL from a supplied HTTP(S) base URL.

Instructions

Encode source and optional config into a bounded pako: token. Optionally create a share URL for an explicitly supplied HTTP(S) baseUrl, without credentials or an existing fragment. Does not validate syntax or open the destination. The token is reversible and contains the source.

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": {
      "code": "<code>"
    },
    "name": "encode_mermaid_share"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesMermaid source text. Syntax is not validated and nothing is rendered.
baseUrlNo
mermaidConfigNoOptional Mermaid config as a JSON object string; stored as untrusted data, never applied here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare this read-only, idempotent, non-destructive and closed-world; the description adds value beyond them by disclosing that the output is bounded, that the token is reversible and embeds the source (a real privacy/size consideration), that the baseUrl may carry no credentials or fragment, and that nothing is validated or opened. That is substantive behavioral context an agent cannot get from the annotation set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, no filler, with the core operation stated first and the caveats after. Every clause carries non-obvious information (bounded token, baseUrl restrictions, no validation, reversibility).

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?

With no output schema, the description must imply the return value; naming the "pako: token" and the optional "share URL" largely does that, but it never states the response shape (whether both are returned together, key names). For a simple three-parameter encoder with full annotations, the rest of the picture is complete.

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 67% and the undocumented parameter is baseUrl; the description fills that gap precisely with its HTTP(S)-only, no-credentials, no-fragment constraints. It also restates the optionality of config and the bounded nature of the encoded payload, though it does not clarify how mermaidConfig is embedded or how the 48000/8000 limits interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: "Encode source and optional config into a bounded pako: token," plus the optional URL-construction behavior. The encode/decode split against the sibling decode_mermaid_share is inferable from the verb, but the sibling is never named, so differentiation is implicit rather than explicit.

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?

"Optionally create a share URL for an explicitly supplied HTTP(S) baseUrl, without credentials or an existing fragment" sets clear preconditions, and "Does not validate syntax or open the destination" rules out two plausible wrong expectations. There is no explicit routing sentence telling an agent when to prefer encode over decode, but the surrounding context makes the direction obvious.

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