Skip to main content
Glama
ShawneilRodrigues

Differentiation MCP Server

by ShawneilRodrigues
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Differentiation MCP Server

A Model Context Protocol (MCP) server that provides comprehensive mathematical differentiation capabilities using both symbolic computation (SymPy) and automatic differentiation (autograd).

Features

Differentiation Tools

The server provides six powerful differentiation tools:

  1. differentiate_symbolic - Compute exact symbolic derivatives using SymPy

    • Supports any order of derivatives

    • Automatic simplification

    • LaTeX output for mathematical notation

  2. differentiate_numerical - Numerical derivatives using autograd

    • First and second order derivatives

    • Evaluation at specific points

    • High precision numerical computation

  3. partial_derivatives - Multivariable function differentiation

    • First-order partials for all variables

    • Mixed partial derivatives

    • Support for any number of variables

  4. gradient_vector - Gradient computation for multivariable functions

    • Symbolic gradient vectors

    • Point evaluation capabilities

    • LaTeX formatted output

  5. chain_rule - Application of the chain rule for composite functions

    • Step-by-step breakdown

    • Automatic substitution and simplification

    • Educational explanations

  6. implicit_differentiation - Differentiation of implicit equations

    • Handles equations of the form F(x,y) = 0

    • Automatic application of implicit differentiation rules

    • Clear step-by-step solutions

Prompts

The server provides educational prompts:

  • differentiation-help: Get guidance on which tool to use for different types of problems

  • calculus-problem-solver: Structured approach to solving calculus problems

Related MCP server: ReasonForge

Dependencies

  • mcp - Model Context Protocol framework

  • autograd - Automatic differentiation library

  • sympy - Symbolic mathematics library

  • numpy - Numerical operations

Installation and Setup

Prerequisites

  • Python 3.12 or higher

  • Virtual environment (created automatically by the project)

Configuration for Claude Desktop

Windows

Add to %APPDATA%/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "differentiation-server": {
      "command": "python",
      "args": ["-m", "differentiation_server"],
      "cwd": "c:\\Users\\shawn\\OneDrive\\Desktop\\diffrentiation",
      "env": {
        "PYTHONPATH": "c:\\Users\\shawn\\OneDrive\\Desktop\\diffrentiation\\src"
      }
    }
  }
}

macOS

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "differentiation-server": {
      "command": "python",
      "args": ["-m", "differentiation_server"],
      "cwd": "/path/to/your/diffrentiation",
      "env": {
        "PYTHONPATH": "/path/to/your/diffrentiation/src"
      }
    }
  }
}

Usage Examples

Symbolic Differentiation

Tool: differentiate_symbolic
Arguments:
- expression: "x**3 + 2*x**2 + x + 1"
- variable: "x"
- order: 1

Numerical Differentiation

Tool: differentiate_numerical
Arguments:
- function_def: "lambda x: anp.sin(x) + x**2"
- point: 1.5707963267948966
- order: 1

Partial Derivatives

Tool: partial_derivatives
Arguments:
- expression: "x**2 + y**2 + x*y"
- variables: ["x", "y"]

Chain Rule

Tool: chain_rule
Arguments:
- outer_function: "sin(u)"
- inner_function: "x**2 + 1"
- variable: "x"

Development

Running the Server

cd diffrentiation
.\.venv\Scripts\activate.bat  # Windows
source .venv/bin/activate     # macOS/Linux

python -m differentiation_server

Debugging

Use the MCP Inspector for debugging:

npx @modelcontextprotocol/inspector python -m differentiation_server

Building

uv sync
uv build

Educational Value

This MCP server is designed to be educational, providing:

  • Step-by-step solutions for complex differentiation problems

  • Clear explanations of mathematical concepts

  • LaTeX formatting for proper mathematical notation

  • Error handling with helpful messages

  • Support for various difficulty levels from basic to advanced calculus

Contributing

The server is built using the Model Context Protocol and follows MCP best practices. Contributions are welcome for:

  • Additional differentiation techniques

  • Enhanced error handling

  • More educational prompts

  • Performance optimizations

License

This project is open source and available under standard licensing terms.

Available Tools

6 tools
chain_ruleB

Apply the chain rule for composite functions

ParametersJSON Schema
NameRequiredDescriptionDefault
variableNoVariable to differentiate with respect tox
inner_varNoVariable name for inner function in outer functionu
inner_functionYesInner function (e.g., 'x**2 + 1')
outer_functionYesOuter function (e.g., 'sin(u)' where u is the inner function)

TDQS

B3.3/5.0
Behavior2/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. It only restates the operation and does not describe return values, output form, simplification behavior, or edge cases such as non-composite inputs.

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 a single front-loaded sentence with no filler. It earns its place by clarifying the target domain ('composite functions'), even though it closely mirrors the tool name.

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?

The schema covers all input parameters, and the description is enough to identify the tool's purpose. However, with no output schema and no behavioral detail, the agent is left to infer the return value and when not to use this tool, making the definition minimally viable but not complete.

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 description coverage is 100%, with each parameter having descriptions and examples or defaults. The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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 description uses a specific verb ('Apply') and identifies the resource ('composite functions') and technique ('chain rule'). It is distinguishable from siblings like gradient_vector and implicit_differentiation, though it does not explicitly state that it returns a derivative.

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

Usage Guidelines3/5

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

The phrase 'for composite functions' implies when the tool should be used, but there is no explicit guidance about when to choose chain_rule over differentiate_symbolic or differentiate_numerical, and no exclusions or alternative routing.

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

differentiate_numericalC

Compute numerical derivatives using autograd for specific function values

ParametersJSON Schema
NameRequiredDescriptionDefault
orderNoOrder of derivative (1 for gradient, 2 for Hessian)
pointYesPoint at which to evaluate the derivative
function_defYesPython function definition using autograd.numpy (e.g., 'lambda x: anp.sin(x) + x**2')

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the computation method. It does not explain whether the result is a scalar, vector, or Hessian matrix, nor what constraints apply to the function definition. The return shape and derivative-order behavior are left to schema and inference.

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 a single, front-loaded sentence with no filler. It places the primary action first and lets the schema handle parameter detail. This is appropriately concise for a straightforward computational tool.

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?

The tool sits among five overlapping siblings and has no annotations or output schema, so the description needs to disambiguate and set expectations. It does neither: no output form, no mention of the Hessian option via 'order', and no guidance for choosing numerical vs symbolic differentiation. An agent could easily select the wrong sibling without opening schemas.

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?

The input schema documents all three parameters with 100% coverage, including the default for 'order' and an example for 'function_def', so the baseline is 3. The description adds no additional parameter-level meaning beyond naming autograd. A higher score would require supplementary semantic detail not already present in the schema.

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 description states a clear verb-resource pair ('Compute numerical derivatives') and identifies the implementation ('using autograd'), which visibly distinguishes it from differentiate_symbolic. It does not explicitly mention evaluating at a point, but the 'point' parameter supports that. Overall the core action is unambiguous.

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 given for when to prefer this tool over differentiate_symbolic, partial_derivatives, gradient_vector, or the other siblings. The word 'numerical' implies a use case, but there is no explicit context, exclusions, or alternatives. An agent must infer the selection criteria from sibling names alone.

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

differentiate_symbolicA

Compute symbolic derivatives of mathematical expressions using SymPy

ParametersJSON Schema
NameRequiredDescriptionDefault
orderNoOrder of derivative (1 for first derivative, 2 for second, etc.)
simplifyNoWhether to simplify the result
variableNoVariable to differentiate with respect to (e.g., 'x')x
expressionYesMathematical expression to differentiate (e.g., 'x**2 + 3*x + 1')

TDQS

A3.5/5.0
Behavior2/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. It states only the computation action and library, but does not mention the output format (e.g., SymPy expression string), error handling for invalid expressions, or any limitations. With no annotations, this is a significant transparency gap.

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 a single, front-loaded sentence that names the action, resource, and library with zero wasted words. It is appropriately sized for a straightforward computational tool.

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?

For a tool with four well-documented parameters and no output schema, the description covers the core purpose but leaves out expected return value format and any behavioral caveats. The completeness is adequate for basic invocation but not rich enough to guide an agent through edge cases or result interpretation.

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 description coverage is 100%, so the schema already documents all parameters with defaults and examples. The description adds no additional parameter-level insight beyond the generic term 'mathematical expressions.' Baseline 3 is appropriate since the schema does the heavy lifting.

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 uses a specific verb ('Compute') and resource ('symbolic derivatives of mathematical expressions'), naming the underlying library (SymPy). The word 'symbolic' directly distinguishes it from the sibling tool differentiate_numerical, and the single-variable focus is implied by the 'variable' parameter.

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

Usage Guidelines3/5

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

No explicit when-to-use or alternative routing is provided. However, the term 'symbolic' strongly implies use when an exact derivative is needed, contrasting with the numerical sibling. This is an implied usage rather than explicit guidance.

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

gradient_vectorB

Compute the gradient vector of a multivariable function

ParametersJSON Schema
NameRequiredDescriptionDefault
pointNoPoint at which to evaluate gradient (optional for symbolic)
variablesNoList of variables
expressionYesMultivariable expression

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'compute the gradient vector' but does not clarify whether the result is symbolic, evaluated at a point, returned as a list, or how the optional point interacts with symbolic computation.

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 a single clear sentence that front-loads the operation with no filler. It is appropriately minimal for a straightforward mathematical tool.

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?

The core operation is clear and the schema covers all parameters, but there is no output schema and no annotation context. A note on return format or a distinguishing remark relative to sibling differentiation tools would make the description more complete for correct tool selection and invocation.

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 description coverage is 100%, so the input schema already documents all three parameters. The description adds no additional parameter-level meaning, but the baseline of 3 is appropriate since the schema does the heavy lifting.

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 description states a specific verb ('Compute') and resource ('gradient vector of a multivariable function'), making the core purpose clear. It does not explicitly distinguish itself from 'partial_derivatives', but the term 'gradient vector' is mathematically standard and self-identifying enough.

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 given on when to use this tool versus sibling tools like 'partial_derivatives', 'differentiate_symbolic', or 'chain_rule'. The agent must infer usage from the name and schema alone, with no stated exclusions or alternative conditions.

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

implicit_differentiationB

Perform implicit differentiation for equations of the form F(x,y) = 0

ParametersJSON Schema
NameRequiredDescriptionDefault
equationYesImplicit equation (e.g., 'x**2 + y**2 - 1' for x² + y² = 1)
dependent_varNoDependent variable (usually 'y')y
independent_varNoIndependent variable (usually 'x')x

TDQS

B3.2/5.0
Behavior2/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. It states the operation but does not explain what is returned (e.g., dy/dx expression), any limitations, or how dependent_var and independent_var affect the result.

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 a single concise sentence with no filler. It is front-loaded with the core operation and stays appropriately brief for the tool's complexity.

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?

With no annotations and no output schema, the description is too thin to be fully actionable. An agent understands the operation but not the expected output, the role of the variable parameters, or how this tool differs from closely related siblings.

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?

The input schema covers 100% of parameters, so the baseline is 3. The description adds the implicit-equation framing but does not enrich the meaning of the parameters beyond what the schema already provides.

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 description uses a specific verb and resource: 'Perform implicit differentiation for equations of the form F(x,y) = 0'. It clearly states the operation and the input context, though it is somewhat close to the tool name.

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

Usage Guidelines3/5

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

The description implies when to use the tool by restricting it to implicit equations of the form F(x,y) = 0. However, it does not explicitly compare it to siblings like differentiate_symbolic or differentiate_numerical, so an agent gets no direct guidance on when not to use this tool.

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

partial_derivativesC

Compute partial derivatives for multivariable functions

ParametersJSON Schema
NameRequiredDescriptionDefault
variablesNoList of variables (e.g., ['x', 'y'])
expressionYesMultivariable expression (e.g., 'x**2 + y**2 + x*y')
mixed_orderNoOrder of partial derivative for each variable (e.g., [1, 1] for ∂²f/∂x∂y)

TDQS

C2.9/5.0
Behavior2/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. It only says 'Compute partial derivatives' and does not explain what is returned, whether it outputs expressions, how mixed/higher-order derivatives are handled, or any limitations. This leaves key behavior unspecified for an agent.

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 front-loaded sentence with no filler. It is appropriately brief, though it could have included a little more operational context without becoming verbose.

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?

There is no output schema and no annotations, so the description needs to explain return behavior and usage context more fully. It does neither, and it leaves the agent without enough information to distinguish this tool from siblings or to understand how mixed_order affects the result.

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 description coverage is 100%, so the schema already documents all three parameters. The description does not add extra meaning or clarify the relationship between variables, expression, and mixed_order beyond what the schema provides, so the baseline score of 3 applies.

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 description states a clear verb ('Compute') and a specific resource ('partial derivatives for multivariable functions'). It conveys the core operation but does not explicitly distinguish itself from sibling tools such as differentiate_symbolic or gradient_vector, 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 Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives like differentiate_symbolic, differentiate_numerical, or gradient_vector. It neither names exclusions nor provides context for choosing between partial_derivatives and related symbolic/numerical differentiation tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • First observedchain_rule
    • First observeddifferentiate_numerical
    • First observeddifferentiate_symbolic
    • First observedgradient_vector
    • First observedimplicit_differentiation
    • First observedpartial_derivatives
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: symbolic vs. numerical differentiation are separated by method, and chain rule/implicit differentiation cover specific techniques. However, partial_derivatives and gradient_vector are closely related since a gradient is essentially the vector of all partial derivatives, which could cause some misselection.

Naming Consistency3/5

Two tools follow a clear verb_noun pattern (differentiate_symbolic, differentiate_numerical), but the remaining four are descriptive noun phrases like partial_derivatives, gradient_vector, chain_rule, and implicit_differentiation. The naming is readable and consistently snake_case, but the structural conventions are mixed.

Tool Count5/5

Six tools is a well-scoped count for a differentiation-focused server. Each tool covers a meaningful aspect of the domain without unnecessary redundancy or bloat.

Completeness4/5

The toolset covers symbolic, numerical, partial, gradient, chain rule, and implicit differentiation, which addresses the core domain well. Minor gaps such as higher-order derivatives or directional derivatives could be added, but they are not obvious dead ends for typical differentiation workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • ReasonForge

    RoyCoding8
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides a suite of deterministic math tools powered by SymPy to handle algebra, calculus, linear algebra, and statistics via the Model Context Protocol. It enables smaller language models to delegate complex computations to a verified symbolic backend for accurate and reliable results.
    Apache 2.0

  • Math MCP Server

    codeprimate
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides powerful symbolic mathematics and statistical analysis capabilities, enabling users to solve equations, compute derivatives and integrals, perform statistical tests, and analyze data through natural language requests.
    4
    MIT

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/ShawneilRodrigues/mcp-differentiation-tool'

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