Skip to main content
Glama
sdiehl
by sdiehl

dsolve_ode

Solve ordinary differential equations (ODEs) using SymPy’s dsolve function. Input an expression and function name to compute and return the solution in LaTeX format. Supports optional solving hints for specific methods.

Instructions

Solves an ordinary differential equation using SymPy's dsolve function.

Args:
    expr_key: The key of the expression (previously introduced) containing the differential equation.
    func_name: The name of the function (previously introduced) to solve for.
    hint: Optional solving method from ODEHint enum. If None, SymPy will try to determine the best method.

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

    # Create a second-order ODE: f''(x) + 9*f(x) = 0
    expr_key = introduce_expression("Derivative(f(x), x, x) + 9*f(x)")

    # Solve the ODE
    result = dsolve_ode(expr_key, "f")
    # Returns solution with sin(3*x) and cos(3*x) terms

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
expr_keyYes
func_nameYes
hintNo
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns a LaTeX string or an error message, which is useful behavioral information. However, it doesn't mention potential limitations (e.g., computational complexity, unsolvable equations), side effects, or performance considerations that would be important for a mathematical solving tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, args, example, returns) and every sentence earns its place. The example is comprehensive but necessary to demonstrate the workflow. No redundant information is present.

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?

Given the complexity of ODE solving (3 parameters, no output schema, no annotations), the description is mostly complete. It explains the purpose, parameters, provides a detailed example, and specifies the return format. However, it lacks information about error conditions beyond 'issues occur' and doesn't mention dependencies on other tools (intro, introduce_function, introduce_expression) in the main description text.

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

Parameters4/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. It explains all three parameters: expr_key (key of expression with the ODE), func_name (function to solve for), and hint (optional solving method from ODEHint enum). The description adds meaning by clarifying that expr_key and func_name refer to 'previously introduced' entities and that hint can be None for automatic method selection.

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?

The description clearly states the tool 'solves an ordinary differential equation using SymPy's dsolve function,' which is a specific verb+resource combination. It distinguishes itself from siblings like solve_algebraically, solve_linear_system, and pdsolve_pde by focusing specifically on ODE solving with SymPy's dsolve.

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 description provides clear context through the example, showing prerequisite steps (intro, introduce_function, introduce_expression) and how to use the tool. However, it doesn't explicitly state when to use this versus alternatives like solve_algebraically or pdsolve_pde, nor does it mention any exclusions or edge cases.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sdiehl/sympy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server