Skip to main content
Glama

Equation.io

by io.equation
OverviewDiscussionsAdmin

Server Details

Create interactive 2D and 3D graphs with validated equations, shareable links, and PNG previews.

Ownership verified
Status
Healthy
Uptime
100.0% over 42 days
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL
Repository
aantthony/equation.io
GitHub Stars
405

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation4/5

decode_graph_url and encode_graph_url are clearly opposite operations, and show_graph is distinguished by rendering. However, encode_graph_url and show_graph both accept the same 'equations' payload and return validation plus share links, so some overlap remains that the descriptions must actively disambiguate.

Naming Consistency5/5

All three tools use a consistent snake_case verb_noun pattern: decode_graph_url, encode_graph_url, show_graph. The verbs (decode/encode/show) are predictable and the shared _graph_url suffix on the link tools reinforces the pattern.

Tool Count4/5

Three tools is a lean but coherent set for a URL/graph service: parse, build, display. It is slightly thin (no standalone validation or examples tool), but each tool earns its place.

Completeness4/5

The full lifecycle for a stateless, URL-based graph is covered: decode an existing link, encode/validate a new one, and render it. There is no explicit update/delete, but since graphs are encoded in URLs rather than stored server-side, that is not a real gap.

Available Tools

3 tools
decode_graph_urlRead a graph linkA
Read-onlyIdempotent
Inspect

Decode an equation.io link (either the #-fragment form or the /g/ share form) into its list of equation rows, so you can edit them and build a new link with encode_graph_url. The rows use the equation.io syntax documented in the "syntax" MCP resource (also at https://equation.io/llms.txt).

NameRequiredDescriptionDefault
urlYesAn equation.io graph URL.

Output Schema

NameRequiredDescription
equationsYes

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, non-open-world behavior, so the bar is lower. The description adds real value beyond them: it discloses that two URL formats are accepted (#-fragment and /g/ share) and points to the authoritative row-syntax resource, which the agent needs to interpret the result.

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?

A single front-loaded sentence gives purpose, output shape, the sibling to chain with, and both accepted URL forms; a short second sentence supplies the syntax reference. No filler or redundancy.

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 an output schema present, return values need not be detailed, yet the description still characterizes the result as a list of equation rows and links the syntax documentation required to read them. Minor gaps remain around malformed-URL/error behavior, but nothing essential for correct invocation is missing.

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% and there is only one parameter, so baseline is 3. The description goes further by enumerating the two accepted URL forms, adding meaning the terse schema text ('An equation.io graph URL') does not convey.

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 (decode) and resource (equation.io link) and names the exact output (its list of equation rows). It also names the sibling encode_graph_url as the inverse operation and distinguishes the two accepted URL forms, so an agent can tell it apart from encode_graph_url and show_graph without opening a schema.

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 a clear workflow context: decode so you can edit the rows and rebuild a link with encode_graph_url, which implicitly routes the agent to the sibling for the reverse direction. It stops short of explicit when-not-to-use guidance and never mentions show_graph, so the sibling set is only partially addressed.

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

encode_graph_urlCreate a graph linkA
Read-onlyIdempotent
Inspect

Build an equation.io graph link, validating every row with the app's parser. Pass the COMPLETE graph in "equations": a flat array of strings, one equation or definition per string, in display order — when editing an existing graph (see decode_graph_url), include unchanged rows too.

Rows can be: equations and inequalities in x,y (curves, regions; z makes it 3D), bare expressions in x, y (scalar fields — a curve is written y = f(x); complex plots via w), points (rows report "draggable"), parametric tuples in u,v — and definitions: "a = 2" (a draggable slider), "f(x) = x^3 - a x", coordinate fields like "r = sqrt(x^2+y^2)" for polar. t animates. Also derivatives d/dx, integrals int[a..b] f dx, sums sum[n=1..N], domain()/conformal()/iter() for complex plots, rgb()/hsl()/oklch() color fields, y' = … slope fields, random variables "X ~ Normal(m, s)"/"P(0<X<2)"/"E(X^2)", and "view(x = -5..5, y = -2..2)"/"camera(theta, phi)" framing rows. That is a menu, not the syntax: before your first non-trivial graph, read the "syntax" MCP resource (also at https://equation.io/llms.txt).

The result returns text and structured data only. "rows" gives each equation's validation result: status "ok" with its kind, or "error" with the parser message. The link is usable only once every row is "ok". Give users the share_url (it unfurls to a link card in chat apps); url is the equivalent #-fragment form. No image is attached to the tool response.

NameRequiredDescriptionDefault
equationsYesEvery equation in the graph, in display order. One equation or definition per string — do not join rows with ";" (inside quoted text a ";" is data, and kept).

Output Schema

NameRequiredDescription
urlYesGraph URL using a #-fragment.
rowsYes
validYes
previewNoStatic preview availability and limitations.
share_urlYesShareable /g/ graph URL.
preview_omitsNo

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: rows are parser-validated, the link is usable only when every row is 'ok', the response is text + structured data with no image attached, and share_url vs url semantics are spelled out. These are exactly the traits annotations cannot carry.

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

Conciseness3/5

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

Front-loaded correctly and organized, but roughly 300 words for a single-parameter tool includes a long enumeration of row types the description itself concedes is 'a menu, not the syntax' and then redirects to the resource. Useful for capability discovery, yet borderline padding for the size.

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?

An output schema exists so return values needn't be explained, and the description still names the rows status shape, both URL forms, and the no-image caveat. Nothing an agent needs to call this correctly is missing.

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 is 3, but the description goes beyond it: 'include unchanged rows too' for edits, the display-order requirement, and the explicit warning not to join rows with ';' while noting a quoted ';' is data. That is real added meaning over the 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?

Opens with a specific verb+resource ('Build an equation.io graph link') and immediately distinguishes itself from the sibling decode_graph_url by naming it for the edit-existing case. An agent can tell encode from decode without opening either schema.

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 a clear use context (editing an existing graph → include unchanged rows, see decode_graph_url) and a prerequisite (read the syntax resource before a first non-trivial graph). It does not address the other sibling show_graph, so the routing picture is not fully closed.

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

show_graphShow an interactive graphA
Read-onlyIdempotent
Inspect

Display an interactive equation.io graph inside the conversation, with editable equations, sliders, pan/zoom, and 3D rotation. Use when the user asks to see or explore a graph. Pass the COMPLETE graph as "equations", one equation or definition per string, preserving unchanged rows when editing. For a slider use "a = 2" then "y = a sin(x)". For advanced syntax read the "syntax" resource (https://equation.io/llms.txt). Returns per-row validation and share links; a row with status "error" is not drawn until its text is corrected and the graph resubmitted. Use encode_graph_url for validation or link-only requests (including share-link preview notes). In clients without UI support, provide share_url.

NameRequiredDescriptionDefault
equationsYesEvery equation in the graph, in display order. One equation or definition per string — do not join rows with ";" (inside quoted text a ";" is data, and kept).

Output Schema

NameRequiredDescription
urlYesGraph URL using a #-fragment.
rowsYes
validYes
share_urlYesShareable /g/ graph URL.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: per-row validation results, share links, and that a row with status 'error' is not drawn until corrected and resubmitted. The no-UI fallback (share_url) is also disclosed.

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-loaded with purpose then usage then mechanics; dense but nearly every sentence carries actionable detail (completeness, slider pattern, error-row behavior, fallback). Slightly long, with the semicolon note partially duplicating the schema.

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?

For a single-required-parameter tool with an output schema, the description covers invocation, editing semantics, error handling, sibling routing, and client-capability fallback. Nothing an agent needs to call it correctly is missing.

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 is 3, but the description adds real meaning: the graph must be COMPLETE, unchanged rows should be preserved when editing, and it supplies a worked slider example ('a = 2' then 'y = a sin(x)'). That is more than the schema conveys, though the semicolon guidance overlaps with the schema text.

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 concrete verb+resource ('Display an interactive equation.io graph inside the conversation') and enumerates the capability set (editable equations, sliders, pan/zoom, 3D rotation). It also implicitly separates itself from the encode/decode siblings by naming encode_graph_url for validation/link-only work.

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?

Explicit trigger ('Use when the user asks to see or explore a graph') plus an explicit alternative and its condition ('Use encode_graph_url for validation or link-only requests'). It even covers the fallback path for clients without UI support.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedencode_graph_url1 field changed
      • changedOutput schema / required
        Previous value: -[
-  "valid",
-  "url",
-  "share_url",
-  "preview",
-  "rows"
-]New value: +[
+  "valid",
+  "url",
+  "share_url",
+  "rows"
+]
  2. 1 tool update
    • Changedshow_graph3 fields changed
      • removedOutput schema / properties / preview
        Removed value: -{
-  "description": "Static preview availability and limitations.",
-  "type": "string"
-}
      • removedOutput schema / properties / preview_omits
        Removed value: -{
-  "items": {
-    "additionalProperties": false,
-    "properties": {
-      "row": {
-        "type": "string"
-      },
-      "why": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "row",
-      "why"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}
      • changedOutput schema / required
        Previous value: -[
-  "valid",
-  "url",
-  "share_url",
-  "preview",
-  "rows"
-]New value: +[
+  "valid",
+  "url",
+  "share_url",
+  "rows"
+]
  3. 1 tool update
    • Addedshow_graph
  4. 4 tool updates
    • Removedcreate_graph
    • Addeddecode_graph_url
    • Addedencode_graph_url
    • Removedread_graph
  5. 2 tool updates
    • First observedcreate_graph
    • First observedread_graph

Related MCP Connectors

Related MCP Servers

Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources