Skip to main content
Glama
The-40-Thieves

codecalc

by The-40-Thieves
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Evaluate Expression

evaluate_expression
Read-onlyIdempotent

Symbolically evaluate math expressions with SymPy: compute derivatives, integrals, series expansions, and closed forms from expressions like 'diff(sin(x)*x, x)'.

Instructions

Use evaluate_expression, not calc_exact, for something other than plain arithmetic on literal values. Symbolically evaluate to a value or closed form via sympify: 'sqrt(144) + 2**10'. Not simplification — for simplified/factored/expanded forms, use symbolic(op="simplify").

Also reaches calculus forms no other tool exposes: diff(expr, x) (derivative), integrate(expr, x) / integrate(expr, (x, a, b)) (indefinite/definite), and series(expr, x, x0, n) (Taylor expansion) — see this parameter's own examples.

Returns value (if the result is a number) or the evaluated expression, plus type.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
expressionYesSymbolic math expression to evaluate via SymPy, e.g. 'integrate(x**2, x)', 'diff(sin(x)*x, x)', 'series(sin(x), x, 0, 6)', 'sqrt(144) + 2**10'

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.13.0
    • changedInput schema / properties / expression / description
      Previous value: -"Symbolic math expression to evaluate via SymPy, e.g. 'integrate(x**2, x)', 'sqrt(144) + 2**10'"New value: +"Symbolic math expression to evaluate via SymPy, e.g. 'integrate(x**2, x)', 'diff(sin(x)*x, x)', 'series(sin(x), x, 0, 6)', 'sqrt(144) + 2**10'"
  2. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / expression / description
      Added value: +"Symbolic math expression to evaluate via SymPy, e.g. 'integrate(x**2, x)', 'sqrt(144) + 2**10'"
  3. Changed1 schema field changedv0.11.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "evaluate_expressionDictOutput",
+  "type": "object"
+}
  4. Changed4 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / expression / title
      Added value: +"Expression"
    • addedInput schema / title
      Added value: +"evaluate_expressionArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  5. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already mark the tool read-only, idempotent, and non-destructive, so the safety burden is covered. The description adds useful behavioral context beyond the annotations: it explains the evaluation mechanism (via sympify), clarifies what it is not, and reveals the shape of the return value: `value` or evaluated expression plus `type`.

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 compact for the complexity it covers, front-loads the key distinguishing guidance first and uses compact inline examples. Every sentence earns its place, though the calculus list plus return note is slightly dense but still readable.

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

Completeness5/5

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

Given the annotations, full parameter coverage, and an output schema, the description is complete: it states what the tool does, when to use it, what it bypasses, and what it returns. An agent has enough guidance to select and invoke it correctly with no material gaps.

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 100%, and the single `expression` parameter already includes rich examples for diff, integrate, series, and arithmetic expressions. The description reinforces those examples and adds context like "closed form," but it mostly relies on the schema rather than introducing substantial new parameter-level meaning.

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 states a clear verb and resource: symbolically evaluate a math expression to a value or closed form via sympify. It explicitly distinguishes itself from calc_exact and symbolic(op="simplify"), so an agent can tell exactly what scope of work this tool covers.

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

Usage Guidelines5/5

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

It names its primary alternative (calc_exact for plain arithmetic on literal values) and explicitly routes simplification to symbolic(op="simplify"). It also states that calculus forms like diff, integrate, and series are uniquely exposed by this tool, leaving no ambiguity about when to select it.

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

Deploy Server

Other Tools