Equation.io

by io.equation

Overview Discussions Admin

Server Details

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

Ownership verified

Status: Healthy
Uptime: 100.0% over 43 days
Last Tested: 2026-10-26 14:47
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.4/5.0

Scored 2026-10-18 07:55 across 3 tools

Disambiguation4/5

decode_graph_url and encode_graph_url are clear inverses, and show_graph is distinguished as the interactive display path. There is some residual overlap since both encode_graph_url and show_graph validate rows and return share links, but the descriptions explicitly steer between them (encode for validation/link-only, show for interactive display).

Naming Consistency5/5

All three names follow a consistent snake_case verb_noun pattern (decode_graph_url, encode_graph_url, show_graph). The graph_url suffix pairing on the codec pair is coherent, and show_graph reads as the same family.

Tool Count4/5

Three tools is lean but well-matched to a narrow graph-encoding utility with no redundant entries. Each tool earns its place, though the surface is on the thin side for anything beyond link/display workflows.

Completeness4/5

The decode-build-display lifecycle covers the core domain of round-tripping equation.io graphs and sharing links, with validation built into encode. The only gap is that syntax knowledge lives in a referenced MCP resource rather than a tool, but that is an acceptable workaround.

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).

Name	Required	Description	Default
`url`	Yes	An equation.io graph URL.

Output Schema

Name	Required	Description
`equations`	Yes

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.

Name	Required	Description	Default
`equations`	Yes	Every 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

Name	Required	Description
`url`	Yes	Graph URL using a #-fragment.
`rows`	Yes
`valid`	Yes
`preview`	No	Static preview availability and limitations.
`share_url`	Yes	Shareable /g/ graph URL.
`preview_omits`	No

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.

Name	Required	Description	Default
`equations`	Yes	Every 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

Name	Required	Description
`url`	Yes	Graph URL using a #-fragment.
`rows`	Yes
`valid`	Yes
`share_url`	Yes	Shareable /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 tool updateOct 18, 2026

Changedencode_graph_url1 field changed

changedOutput schema / required

Previous value: -[
-  "valid",
-  "url",
-  "share_url",
-  "preview",
-  "rows"
-]New value: +[
+  "valid",
+  "url",
+  "share_url",
+  "rows"
+]

1 tool updateSep 21, 2026

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"
+]

1 tool updateSep 14, 2026
- Addedshow_graph
2 tool updatesSep 14, 2026
- First observeddecode_graph_url
- First observedencode_graph_url

Publisher details

Operator: Anthony Foster · Publisher source
Operator website: https://equation.io/about/
Vendor relationship: First-party
Documentation: https://equation.io/about/
Trust center: Not applicable
Restrictions: Not applicable

Related MCP Servers

Adologyofficial
Marketing Social Media
adologyai
A
license
Not graded
quality
C
maintenance
Perplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
Updated a month ago (2026-09-11 19:20 UTC)
2
Apache 2.0
Competitor Monitor AI MCP
Marketing Research & Data AI & Machine Learning
CSOAI-ORG
A
license
C
quality
B
maintenance
Competitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 19 days ago (2026-10-08 01:01 UTC)
11
3 npm
54 PyPI
MIT
Citesurf MCP
Marketing Search Monitoring
citesurf
A
license
A
quality
C
maintenance
Enables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.
Updated 6 months ago (2026-04-23 11:46 UTC)
16
4 npm
1
MIT
industrylens-mcpofficial
Research & Data
IndustryLensOp
A
license
Not graded
quality
B
maintenance
Browse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.
Updated 2 months ago (2026-08-17 15:55 UTC)
MIT