Symbolic Algebra MCP Server

limit_expression

Computes symbolic limits as a variable approaches a specified point, including two-sided and one-sided cases, and indicates when a limit does not exist.

Instructions

Computes the limit of an expression as a variable tends to a point, using SymPy's limit.

Args:
    expr_key: The key of the expression (previously introduced).
    var_name: The variable (previously introduced) that tends to the point.
    point: The limit point, e.g. "0", "1/2", "pi/2", "oo" (+infinity), "-oo".
        Parsed without eval: only numbers, introduced variables, oo/inf/pi/E/I,
        arithmetic operators and sqrt/exp/log/sin/cos/tan/Rational are accepted.
    direction: "+-" for the two-sided limit (default), "+" from the right, "-" from the left.
        Ignored for limits at +oo or -oo.

Example:
    intro("x", [Assumption.REAL], [])
    expr_key = introduce_expression("sin(x)/x")
    result_key = limit_expression(expr_key, "x", "0")
    # 1
    expr_key = introduce_expression("(1 + 1/x)**x")
    result_key = limit_expression(expr_key, "x", "oo")
    # e

Returns:
    A key for the limit. Returns an error message if the limit does not exist
    (one-sided limits differ, or the expression oscillates).

Input Schema

Name	Required	Default
`point`	Yes
`expr_key`	Yes
`var_name`	Yes
`direction`	No	+-

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the no-eval parsing restriction and the exact whitelist of accepted token types, the direction default of '+-' and that direction is ignored at ±oo, and the error behavior when a limit does not exist (differing one-sided limits or oscillation). These are non-obvious traits an agent could not infer from the schema.

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 one-sentence purpose followed by Args/Example/Returns in a predictable order, with no filler prose. The second worked example is valuable, though the example's trailing '# 1' and '# e' comment results slightly overlap what the Returns section already covers.

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 four-parameter symbolic tool with an output schema and zero schema description coverage, the description supplies the missing prerequisites, point-syntax constraints, direction semantics, and failure mode. An agent has everything needed to invoke it correctly and interpret a returned key versus an error message.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it does: all four parameters are explained, including the accepted syntax for 'point' ("0", "1/2", "pi/2", "oo", "-oo" plus operators and functions) and the meaning plus default of the direction enum. This adds substantial meaning beyond bare title/type fields.

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?

States a specific verb and mathematical resource: computes the limit of an expression as a variable tends to a point, via SymPy's limit. The domain term 'limit' is unambiguous against siblings like integrate_expression or series_expansion, though the description never explicitly names an alternative to route away from.

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?

The Args section establishes the prerequisite that expr_key and var_name must have been 'previously introduced', which tells the agent this tool is not a first step. The worked example further anchors the intended call sequence (intro → introduce_expression → limit_expression). No explicit when-not-use guidance is given.

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