Skip to main content
Glama

sympy_mcp_calculus_operation

Perform calculus operations including differentiation, integration, limits, and series expansion on mathematical expressions using symbolic computation.

Instructions

Do calculus operations like diff, integrate, limit, series

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationYes
exprYes
symNo
nNo
lowerNo
upperNo
pointNo
directionNo+
series_nNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Handler function implementing the core logic for the 'sympy_mcp_calculus_operation' tool, supporting diff, integrate, limit, and series operations using SymPy.
    def calculus_operation(
        operation: CalculusOperation,
        expr: str,
        sym: Optional[str] = None,
        # diff parameters
        n: int = 1,
        # integrate parameters
        lower: Optional[Union[int, float, str]] = None,
        upper: Optional[Union[int, float, str]] = None,
        # limit parameters
        point: Union[int, float, str] = 0,
        direction: Literal["+", "-"] = "+",
        # series parameters
        series_n: int = 6,
    ) -> str:
        """
        Unified interface for calculus operations.
    
        Args:
            operation: The calculus operation to perform. One of:
                - 'diff': Differentiate the expression
                - 'integrate': Integrate the expression
                - 'limit': Compute the limit of the expression
                - 'series': Compute the series expansion of the expression
            expr: The expression to process as a string
            sym: The symbol to differentiate/integrate with respect to, or the variable for limits/series
            n: Order of derivative for 'diff' or order of series expansion for 'series' (default: 1 for 'diff', 6 for 'series')
            lower: Lower limit for definite integral (only for 'integrate')
            upper: Upper limit for definite integral (only for 'integrate')
            point: The point to approach for 'limit' or about which to expand for 'series' (default: 0)
            direction: Direction to approach from for 'limit' ('+' or '-', default: '+')
    
        Returns:
            str: The result of the operation as a string
    
        Examples:
            >>> calculus_operation('diff', 'x**2 + 2*x + 1', 'x')
            '2*x + 2'
            >>> calculus_operation('integrate', '2*x + 2', 'x')
            'x**2 + 2*x'
            >>> calculus_operation('limit', 'sin(x)/x', 'x', point=0)
            '1'
            >>> calculus_operation('series', 'exp(x)', 'x', point=0, n=3)
            '1 + x + x**2/2 + O(x**3)'
        """
        # Convert string to SymPy expression
        expr_obj = sympify(expr)
    
        # Convert symbol string to Symbol if provided
        sym_obj = sympify(sym) if sym is not None else None
    
        if operation == "diff":
            # Handle differentiation
            if sym_obj is None:
                raise ValueError("Symbol must be provided for differentiation")
            return str(_diff(expr_obj, sym_obj, n))
    
        elif operation == "integrate":
            # Handle integration
            if sym_obj is None:
                raise ValueError("Symbol must be provided for integration")
    
            # Check for definite integral
            if lower is not None or upper is not None:
                # Definite integral
                lower_val = sympify(lower) if isinstance(lower, str) else lower
                upper_val = sympify(upper) if isinstance(upper, str) else upper
                return str(_integrate(expr_obj, (sym_obj, lower_val, upper_val)))
            else:
                # Indefinite integral
                return str(_integrate(expr_obj, sym_obj))
    
        elif operation == "limit":
            # Handle limits
            if sym_obj is None:
                raise ValueError("Symbol must be provided for limit")
    
            # Convert point to SymPy expression if it's a string
            point_val = sympify(point) if isinstance(point, str) else point
    
            return str(_limit(expr_obj, sym_obj, point_val, direction))
    
        elif operation == "series":
            # Handle series expansion
            if sym_obj is None:
                raise ValueError("Symbol must be provided for series expansion")
    
            # Convert point to SymPy expression if it's a string
            point_val = sympify(point) if isinstance(point, str) else point
    
            return str(_series(expr_obj, sym_obj, point_val, series_n).removeO())
    
        else:
            valid_ops = get_args(CalculusOperation)
            raise ValueError(f"Invalid operation. Must be one of: {valid_ops}")
  • Registration of the calculus_operation handler as the 'sympy_mcp_calculus_operation' tool in the FastMCP server.
    sympy_mcp.tool(
        calculus_operation,
        description="Do calculus operations like diff, integrate, limit, series",
    )
  • Type definitions used for input schema validation, including CalculusOperation literal types and parameter annotations in the handler.
    from typing import Optional, Literal, get_args, Union
    from sympy import (
        sympify,
        diff as _diff,
        integrate as _integrate,
        limit as _limit,
        series as _series,
    )
    
    # Define operation types for type hints
    CalculusOperation = Literal["diff", "integrate", "limit", "series"]
Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only lists operation types without explaining what the tool does (e.g., computes derivatives, integrals, etc.), expected outputs, error conditions, or performance traits. This is inadequate for a tool with 9 parameters and complex operations.

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 description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, though it could be more structured by separating operation examples. The brevity is appropriate but under-specified.

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

Completeness2/5

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

Given the tool's complexity (9 parameters, calculus operations), no annotations, and 0% schema coverage, the description is incomplete. While an output schema exists, the description lacks essential context like input formats, mathematical assumptions, or error handling. It doesn't provide enough information for reliable use.

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

Parameters1/5

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

Schema description coverage is 0%, meaning parameters like 'expr', 'sym', 'n', 'lower', 'upper', 'point', 'direction', and 'series_n' are undocumented in the schema. The description adds no meaning beyond the operation names, failing to compensate for the coverage gap. For example, it doesn't clarify that 'expr' is a mathematical expression string or how parameters interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Do calculus operations like diff, integrate, limit, series' states the general purpose (calculus operations) and lists examples, but it's vague about the specific resource (mathematical expressions) and doesn't distinguish from sibling tools like sympy_mcp_algebra_operation or sympy_mcp_equation_operation. It provides a basic idea but lacks specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description lists operations but doesn't mention prerequisites, when to choose this over other sympy tools, or any exclusions. This leaves the agent without context for tool selection.

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

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/abhiphile/fermat-mcp'

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