Symbolic Algebra MCP Server

pdsolve_pde

Solves partial differential equations symbolically from a stored expression and target function name, returning the solution as LaTeX for symbolic algebra workflows.

Instructions

Solves a partial differential equation using SymPy's pdsolve function.

Args:
    expr_key: The key of the expression (previously introduced) containing the PDE.
             If the expression is not an equation (Eq), it will be interpreted as
             PDE = 0.
    func_name: The name of the function (previously introduced) to solve for.
               This should be a function of multiple variables.

Example:
    # First introduce variables and a function
    intro("x", [Assumption.REAL], [])
    intro("y", [Assumption.REAL], [])
    introduce_function("f")

    # Create a PDE: 1 + 2*(ux/u) + 3*(uy/u) = 0
    expr_key = introduce_expression(
        "Eq(1 + 2*Derivative(f(x, y), x)/f(x, y) + 3*Derivative(f(x, y), y)/f(x, y), 0)"
    )

    # Solve the PDE
    result = pdsolve_pde(expr_key, "f")
    # Returns solution with exponential terms and arbitrary function

Returns:
    A LaTeX string representing the solution. Returns an error message string if issues occur.

Input Schema

Name	Required	Description	Default
`hint`	No
`expr_key`	Yes
`func_name`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A3.6/5.0

Behavior3/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 add real value: it explains that a non-Eq expression is treated as PDE = 0 and that failures surface as an error-message string rather than an exception. It says nothing about side effects (e.g., whether the solution is registered as a new expression key in session state), performance limits, or which PDE classes pdsolve can actually handle.

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?

Purpose is front-loaded in the opening sentence, followed by Args, a concrete Example, and Returns. The example is longer than strictly necessary but earns its space by demonstrating the prerequisite call sequence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the Returns note is supplementary, and the Args plus example cover the required parameters well. The unresolved gap is the undocumented 'hint' enum and the absence of any statement about state side effects, which an agent needs before calling a stateful computer-algebra tool.

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

Parameters3/5

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

Schema coverage is 0% (titles only), so the description must compensate. It does explain expr_key (key of a previously introduced expression, non-Eq treated as = 0) and func_name (a previously introduced function of multiple variables), but the optional 'hint' parameter — an enum of four PDE model types — is never mentioned anywhere, leaving one third of the parameters opaque.

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?

The first sentence gives a specific verb and resource ('Solves a partial differential equation using SymPy's pdsolve') that is clearly distinct from dsolve_ode and the algebra/calculus siblings. It does not explicitly name the ODE counterpart as an alternative, so it stops short of full sibling differentiation.

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 worked example implicitly spells out the required precondition chain: variables and the function must be introduced with intro/introduce_function before introduce_expression creates the PDE key. That gives clear usage context, but there is no explicit 'use this instead of X' routing against dsolve_ode or a statement of when pdsolve will fail.

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