Create interactive 2D and 3D graphs with validated equations, shareable links, and PNG previews.
Scored across 3 tools
Each tool has a distinct purpose: decode converts links to data, encode builds links without display, and show_graph renders interactive graphs. The descriptions clearly delineate when to use encode vs show, and decode is uniquely for reading graphs.
Two tools follow a clear verb_noun pattern (decode_graph_url, encode_graph_url), but show_graph deviates slightly from the '_url' suffix. Still, the naming is generally predictable and readable.
With only 3 tools, the surface is minimal yet adequately covers core graph operations (decode, encode, display). However, the toolkit might benefit from a dedicated validation tool to avoid overloading encode, but the count is borderline acceptable.
The three tools form a complete round-trip: decode existing graphs, encode new ones, and display interactive graphs. Missing an update or delete tool is unnecessary since graphs are just arrays of equations that can be edited via encode, so the domain is fully covered.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | An equation.io graph URL. |
| Name | Required | Description |
|---|---|---|
| equations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that it handles both URL forms and outputs a list of equation rows, which is useful. However, the output schema already specifies the return structure, and annotations declare read-only/ non-destructive. It doesn't cover edge cases like invalid URLs or decoding failure, but given the annotations cover safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is informative and front-loaded with the main action, then details the input forms and the purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (single parameter), has a clear output schema, and annotations cover the read-only nature. The description covers the input forms and purpose, which is everything an agent needs to call it correctly and understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'url' parameter as an equation.io graph URL, so coverage is 100%. The description adds value by specifying the accepted forms (#-fragment or /g/), which is beyond the schema, but it's a minor addition. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: decodes an equation.io link into a list of equation rows. It specifies both URL forms (#-fragment and /g/ share) and mentions the purpose (to edit and rebuild via encode_graph_url), which distinguishes it from its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (when you need to edit the graph's rows) and names the alternative for the reverse operation (encode_graph_url). This is a clear usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a link that opens the equation.io grapher with the given equations already rendered, validating every row through the app's own 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 the unchanged rows too.
Rows can be: equations and inequalities in x,y (curves, regions; z makes it 3D), bare expressions (scalar fields; 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, 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" is the validation verdict; if a row fails validation, fix it and call again. Give users the share_url (it unfurls to a preview card in chat apps); url is the equivalent #-fragment form. "preview" and "preview_omits" describe the share link's simplified static preview (t = 0, 3D as wireframes), which draws less than the interactive app. 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). |
| Name | Required | Description |
|---|---|---|
| url | Yes | Graph URL using a #-fragment. |
| rows | Yes | |
| valid | Yes | |
| preview | Yes | Static preview availability and limitations. |
| share_url | Yes | Shareable /g/ graph URL. |
| preview_omits | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe to call. The description adds substantial behavioral context beyond that: it explains that the response returns text and structured data only, that 'rows' is a validation verdict requiring a retry on failure, and describes the preview/omits behavior (static preview at t=0, 3D as wireframes). It also notes no image is attached, which is non-obvious. This goes well beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and dense, but the density is justified by the tool's complexity. It is structured logically: purpose first, then row examples, then a pointer to a syntax resource, then response details. However, it could be tightened—some examples (like the list of random variables) feel exhaustive and could be trimmed to a few representative cases. It is not minimal, but it earns its length for a tool that accepts many grammar variants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (many row types, validation, response semantics, preview behavior) and the presence of an output schema, the description covers all essential aspects. It explains how to construct the input, how to handle validation failures, what fields the response contains (rows, share_url, url, preview, preview_omits), and even links to an external syntax resource. Nothing critical is missing for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the tool description massively enriches the parameter semantics. It details the allowed row types (equations, inequalities, bare expressions, parametric tuples, definitions, coordinate fields, derivatives, integrals, sums, slope fields, random variables, view/camera rows) and explains the 'draggable' concept for points. It also clarifies the 'equations' array is flat and ordered. This transforms a bare array-of-strings schema into a rich, actionable spec.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb ('Build a link') and a specific resource ('the equation.io grapher'), and immediately states the key behavior (validation through the app's parser). It clearly differentiates from the sibling decode_graph_url by framing the encode direction and even mentions 'when editing an existing graph (see decode_graph_url)'. This gives the agent a distinct mental model without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to create or update a graph link) and explicitly points to decode_graph_url for reading existing graphs, with the instruction to include unchanged rows when editing. It also gives a practical usage hint: before the first non-trivial graph, read the 'syntax' MCP resource. It lacks a formal 'when not to use' statement, but the direction is clear enough to score a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the same validation and share links as encode_graph_url; fix invalid rows before presenting the graph as correct. Use encode_graph_url for validation or link-only requests. 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). |
| Name | Required | Description |
|---|---|---|
| url | Yes | Graph URL using a #-fragment. |
| rows | Yes | |
| valid | Yes | |
| preview | Yes | Static preview availability and limitations. |
| share_url | Yes | Shareable /g/ graph URL. |
| preview_omits | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds context about interactivity, return of validation and share links (same as encode_graph_url), and a fallback for clients without UI support. It does not contradict annotations and provides meaningful behavioral detail beyond the structured fields, though it could clarify error handling or exact response structure if the output schema were absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but each sentence carries essential information: purpose, usage, parameter format, example, resource link, and fallback. It is front-loaded with the core purpose and structured logically. It could be slightly tightened, but the length is justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, annotations, and an output schema, the description covers all necessary aspects: when to use, how to format input, examples, validation behavior, and fallback handling. It also references an external syntax resource for advanced cases. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the equations array at 100% coverage, but the description adds significant value: it explains the complete graph must be passed, one equation per string, preserving unchanged rows, and provides a concrete slider syntax example. It also warns against joining rows with ';'. This goes well beyond the schema and compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays an interactive equation.io graph with specific features (editable equations, sliders, pan/zoom, 3D rotation). It distinguishes itself from encode_graph_url by noting it is for display and exploration, while encode_graph_url is for validation or link-only requests. The verb 'display' and resource 'graph' are precise, and the sibling differentiation is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use when the user asks to see or explore a graph' and directs link-only or validation requests to encode_graph_url. It also provides detailed usage instructions: passing the complete graph, preserving unchanged rows, and giving a slider example. This leaves no ambiguity about when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
show_graphdecode_graph_urlencode_graph_url
Add one secure layer between your agents and this server.
