Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TI 84 math practice MCP Find the roots, vertex, and opening direction for y = -2x^2 + 4x - 1"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small local companion to TI 84 Calculator Online. The website provides a browser graphing calculator with a keypad, Y= input, graph, tables, lists, and matrices. This MCP server helps prepare and check two common practice tasks; it does not control or replace the website.
quadratic_report calculates the discriminant, roots, vertex, opening direction, and a starting x-window for ax² + bx + c.
summary_statistics calculates count, min/max, mean, median, and population and sample standard deviations from a numeric list.
get_official_links returns the calculator and guide pages.
For a quadratic, work out the roots on paper, then enter the function in the TI 84 Calculator Online Y= screen and compare the graph, vertex, and table. The suggested window is only a starting point; zoom and trace as needed. For statistics, compare both sample and population standard deviations so you choose the one your assignment asks for.
Node.js 20.18.1 or newer:
npm install
npm test
node index.mjsConfigure your MCP client to start node /absolute/path/to/ti84-mcp/index.mjs over stdio. No login or network request is made by this server. MIT license; see LICENSE.
Return the online calculator and guide pages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does not say whether the links are static or fetched live, how many are returned, or what the return structure looks like.
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?
A single short sentence with no filler and the purpose front-loaded. It is efficient, though its brevity is part of why key details are missing.
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?
With no annotations and no output schema, the description is the only source of behavioral information, and it fails to describe the return value (link count, format, source domain). For a simple lookup tool this is a noticeable gap, though the tool's scope is small.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies for a no-parameter definition.
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 has a verb ('Return') and objects ('online calculator and guide pages'), and the title adds the 'Official TI 84' subject, so the gist is a link-list tool. However, 'return ... pages' is vague about what is actually returned (URLs? a list? a single page?) and gives no differentiation from the sibling tools.
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?
There is no statement of when to use this tool, no prerequisites, and no mention of alternatives among the siblings (quadratic_report, summary_statistics). The agent must infer that it is a static reference lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute discriminant, roots, vertex, and a starting x-window for graph practice.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| c | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries full behavioral burden. It discloses the complete set of computed results, which is meaningful for a pure function, but says nothing about degenerate inputs (a=0), complex vs. real roots, precision, output format, or error behavior — real concerns for a quadratic solver.
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?
One front-loaded sentence with zero filler and the result set stated up front. It is arguably undersized given the documentation gaps, but not wasteful.
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 simple 3-parameter stateless calculator with no output schema, the description covers what comes back but leaves the input contract and edge-case behavior undocumented. Adequate at a minimum-viable level, not complete.
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?
Schema description coverage is 0% and the description never mentions the three parameters. A knowledgeable agent can infer a, b, c are the quadratic coefficients from the tool name, but the description does not confirm the convention, sign order, or handling of non-numeric input, so it fails to compensate for the coverage gap.
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?
A concrete verb ("Compute") plus an enumerated set of resource-like outputs (discriminant, roots, vertex, x-window) makes the tool's function unmistakable. The siblings (summary_statistics, get_official_links) are unrelated domains, so differentiation is trivially satisfied, though the description never says so.
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?
"for graph practice" hints at an educational context, but there is no explicit when-to-use, when-not-to-use, prerequisite, or alternative. The agent must infer invocation conditions entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute mean, median, range, and population/sample standard deviations for a small list.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It helpfully enumerates the computed outputs and flags a scale constraint ('small list'), but it does not clarify the 'population/sample standard deviations' ambiguity (both computed? which flag?), nor return shape, ordering, or behavior on edge inputs.
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?
A single front-loaded sentence that states the operation and every computed statistic with zero filler. Nothing is wasted.
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?
No output schema exists, so the description's enumeration of computed statistics partially covers the return value. However, it leaves gaps on parameter bounds, the population-vs-sample ambiguity, and numeric formatting/edge cases that an agent would want before calling.
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?
One parameter at 0% schema description coverage. The description only vaguely gestures at the constraint via 'small list', without stating the 1–1000 item bounds or that values must be numbers, so it fails to compensate for the undocumented schema.
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 names a specific verb ('compute') and enumerates the exact statistics produced (mean, median, range, population/sample standard deviations) over a list. It is unambiguous about what the tool does. It doesn't differentiate from siblings, but the siblings (quadratic_report, get_official_links) are unrelated enough that differentiation adds little.
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?
There is no explicit guidance on when to use this tool or when not to. The phrase 'for a small list' hints at an intended scale but gives no threshold or exclusions, leaving usage context to inference.
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.
v0.1.0get_official_linksquadratic_reportsummary_statisticsScored across 3 tools
Each tool targets a clearly distinct operation: quadratic analysis, descriptive statistics, and link retrieval. There is no realistic way for an agent to confuse these purposes.
Two tools use noun-phrase names (quadratic_report, summary_statistics) while one uses a verb_noun pattern (get_official_links). The names are readable but the convention is mixed rather than predictable.
Three tools is on the thin side, but each covers a distinct, useful function for a narrow math-practice helper. The scope is small but not mismatched.
The surface covers quadratic analysis, basic statistics, and reference links, but omits other likely practice areas such as linear equations, systems, trigonometry, or general graphing windows. These are notable gaps for a broader TI-84 math-practice domain.
Exact arithmetic, algebra, calculus, physics, chemistry and finance with a checkable formula.
Step-by-step solver for linear/quadratic equations in one variable, signs and ± always right.
Transform your data analysis with our Data Compute & Stats Bot. Effortlessly calculate descriptive
Free deterministic tools for math, data transforms, dates, text, statistics, finance, and units.