Symbolic Algebra MCP Server

series_expansion

Computes Taylor, Laurent, or Puiseux series expansions of symbolic expressions around a specified point to a chosen order, with an option to omit the remainder term.

Instructions

Computes a Taylor/Laurent/Puiseux expansion (développement limité) using SymPy's series.

Args:
    expr_key: The key of the expression (previously introduced) to expand.
    var_name: The variable (previously introduced) of the expansion.
    point: The expansion point, e.g. "0", "1", "pi/2", "oo". Parsed without eval
        with the same rules as limit_expression. Defaults to "0".
    order: Terms up to (var - point)**(order - 1) are kept, followed by O((var - point)**order).
        Must be between 1 and 50. Defaults to 6.
    remove_order_term: If True, drop the O(...) remainder and return the truncated polynomial.

Example:
    intro("x", [Assumption.REAL], [])
    expr_key = introduce_expression("exp(x)")
    result_key = series_expansion(expr_key, "x", "0", 4)
    # 1 + x + x^2/2 + x^3/6 + O(x^4)

Returns:
    A key for the expansion.

Input Schema

Name	Required	Default
`order`	No
`point`	No	0
`expr_key`	Yes
`var_name`	Yes
`remove_order_term`	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.4/5.0

Behavior4/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 well: it discloses defaults (point='0', order=6), the hard bound 1–50 on order, that point is parsed without eval, exactly which terms are kept and which O(...) term is appended, and that remove_order_term truncates. It does not say how out-of-range order or unknown keys fail, which is the main remaining gap.

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?

The first sentence front-loads what the tool does, followed by structured Args/Example/Returns blocks with no filler. The worked example is long but earns its place by demonstrating the key-chaining convention; the Returns section is slightly thin relative to the rest.

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?

For a 5-parameter symbolic tool with a stateful key convention, the description covers inputs, defaults, truncation semantics, and the example end-to-end. Since an output schema exists, the brief 'Returns: a key' note suffices; only error/failure behavior is left unaddressed.

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 coverage is 0%, so the description must compensate, and it does: every parameter is explained, including the non-obvious semantics of order ('terms up to (var - point)**(order - 1) are kept'), accepted point formats with examples, and the effect of remove_order_term. This is meaningfully richer than the bare schema types.

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 and resource: computes a Taylor/Laurent/Puiseux expansion (développement limité) via SymPy's series. The parenthetical synonym and named algorithm make it unambiguous versus siblings like limit_expression or expand_expression.

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 example workflow makes preconditions explicit: the variable must be introduced via intro() and the expression via introduce_expression() before calling, and point parsing is stated to follow limit_expression's rules. It stops short of saying when to prefer this over limit_expression or which sibling handles non-series approximations.

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