Skip to main content
Glama
nilay320

Tavily Web Search MCP Server

by nilay320

scientific_calculator

Evaluate mathematical expressions with scientific functions, including trigonometry, logarithms, exponentials, and complex numbers, using radians by default.

Instructions

Evaluate mathematical expressions using a scientific calculator.

Supports:

  • Basic arithmetic: +, -, *, /, //, %, **

  • Scientific functions: sin, cos, tan, asin, acos, atan, sinh, cosh, tanh

  • Logarithmic functions: log, log10, log2, ln (natural log)

  • Exponential functions: exp, sqrt, cbrt

  • Constants: pi, e, tau

  • Complex numbers: 1+2j, complex operations

  • Trigonometric functions work with radians by default

  • Use degrees(x) to convert radians to degrees, radians(x) to convert degrees to radians

Examples:

  • "sin(pi/2)" -> 1.0

  • "log10(100)" -> 2.0

  • "sqrt(16)" -> 4.0

  • "2**3" -> 8

  • "exp(1)" -> 2.718281828459045

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
expressionYes

Implementation Reference

  • The complete handler for the 'scientific_calculator' tool. Registered via @mcp.tool() decorator. Safely evaluates mathematical expressions using Python's eval() with a restricted namespace containing math functions (sin, cos, log, etc.), constants (pi, e), and complex number support. Includes comprehensive error handling and result formatting for real and complex numbers.
    @mcp.tool()
    def scientific_calculator(expression: str) -> str:
        """
        Evaluate mathematical expressions using a scientific calculator.
        
        Supports:
        - Basic arithmetic: +, -, *, /, //, %, **
        - Scientific functions: sin, cos, tan, asin, acos, atan, sinh, cosh, tanh
        - Logarithmic functions: log, log10, log2, ln (natural log)
        - Exponential functions: exp, sqrt, cbrt
        - Constants: pi, e, tau
        - Complex numbers: 1+2j, complex operations
        - Trigonometric functions work with radians by default
        - Use degrees(x) to convert radians to degrees, radians(x) to convert degrees to radians
        
        Examples:
        - "sin(pi/2)" -> 1.0
        - "log10(100)" -> 2.0
        - "sqrt(16)" -> 4.0
        - "2**3" -> 8
        - "exp(1)" -> 2.718281828459045
        """
        try:
            # Create a safe namespace with mathematical functions and constants
            safe_dict = {
                # Mathematical functions
                'sin': math.sin, 'cos': math.cos, 'tan': math.tan,
                'asin': math.asin, 'acos': math.acos, 'atan': math.atan,
                'atan2': math.atan2,
                'sinh': math.sinh, 'cosh': math.cosh, 'tanh': math.tanh,
                'asinh': math.asinh, 'acosh': math.acosh, 'atanh': math.atanh,
                'log': math.log, 'log10': math.log10, 'log2': math.log2,
                'ln': math.log,  # Natural logarithm alias
                'exp': math.exp, 'sqrt': cmath.sqrt, 'cbrt': lambda x: x**(1/3),
                'pow': pow, 'abs': abs,
                'ceil': math.ceil, 'floor': math.floor, 'trunc': math.trunc,
                'round': round,
                'degrees': math.degrees, 'radians': math.radians,
                'factorial': math.factorial,
                'gcd': math.gcd, 'lcm': math.lcm if hasattr(math, 'lcm') else lambda a, b: abs(a*b) // math.gcd(a, b),
                
                # Constants
                'pi': math.pi, 'e': math.e, 'tau': math.tau,
                'inf': math.inf, 'nan': math.nan,
                
                # Complex number functions
                'complex': complex, 'real': lambda x: x.real if isinstance(x, complex) else x,
                'imag': lambda x: x.imag if isinstance(x, complex) else 0,
                'conjugate': lambda x: x.conjugate() if hasattr(x, 'conjugate') else x,
                'phase': cmath.phase, 'polar': cmath.polar, 'rect': cmath.rect,
                
                # Allow built-in mathematical operations
                '__builtins__': {}
            }
            
            # Replace common mathematical notation
            expression = expression.replace('^', '**')  # Allow ^ for exponentiation
            expression = expression.replace('mod', '%')  # Allow mod for modulo
            
            # Evaluate the expression
            result = eval(expression, safe_dict)
            
            # Format the result nicely
            if isinstance(result, complex):
                if abs(result.imag) < 1e-10:  # Essentially real
                    real_part = result.real
                    if abs(real_part) < 1e-10:
                        return "0"
                    elif abs(real_part - round(real_part)) < 1e-10:
                        return str(int(round(real_part)))
                    else:
                        return str(real_part)
                else:
                    real_str = str(int(result.real)) if abs(result.real - round(result.real)) < 1e-10 else str(result.real)
                    imag_str = str(int(result.imag)) if abs(result.imag - round(result.imag)) < 1e-10 else str(result.imag)
                    
                    if result.real == 0:
                        return f"{imag_str}j" if result.imag != 1 else "j" if result.imag == 1 else "-j"
                    else:
                        if result.imag >= 0:
                            imag_part = f" + {imag_str}j" if result.imag != 1 else " + j"
                        else:
                            imag_part = f" - {abs(float(imag_str))}j" if result.imag != -1 else " - j"
                        return f"{real_str}{imag_part}"
            elif isinstance(result, float):
                # Round very small numbers to avoid floating point precision issues
                if abs(result) < 1e-10:
                    return "0"
                elif abs(result - round(result)) < 1e-10:
                    return str(int(round(result)))
                else:
                    return str(result)
            else:
                return str(result)
                
        except ZeroDivisionError:
            return "Error: Division by zero"
        except ValueError as e:
            return f"Error: Invalid mathematical operation - {str(e)}"
        except OverflowError:
            return "Error: Result too large to compute"
        except TypeError as e:
            return f"Error: Invalid expression type - {str(e)}"
        except SyntaxError:
            return "Error: Invalid mathematical expression syntax"
        except Exception as e:
            return f"Error: {str(e)}"
  • server.py:29-29 (registration)
    The @mcp.tool() decorator registers the scientific_calculator function as an MCP tool, using its signature and docstring for schema inference.
    @mcp.tool()
  • Function signature defines input schema (expression: str) and output (str), with detailed docstring describing supported operations, examples, and usage.
    def scientific_calculator(expression: str) -> str:
Behavior4/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 does this well by specifying the calculator's capabilities (scientific functions, complex numbers), default behavior (trigonometric functions work with radians), and conversion utilities (degrees, radians). However, it doesn't mention error handling, precision limits, or performance characteristics that would be useful 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 well-structured with a clear purpose statement followed by categorized bullet points and examples. Every sentence earns its place by providing specific, actionable information. It could be slightly more concise by combining some bullet points, but overall it's efficiently organized and front-loaded with the core purpose.

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 tool's moderate complexity (mathematical evaluation with many functions), no annotations, no output schema, and low schema coverage, the description does an excellent job of providing context. It covers capabilities, syntax, defaults, and examples. The main gap is the lack of information about return values or error cases, which would be helpful since there's no output schema.

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

Parameters5/5

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

The input schema has 0% description coverage with only one parameter 'expression' of type string. The description compensates fully by providing extensive semantic context: it explains what the expression parameter should contain (mathematical notation), lists all supported operations and functions, shows syntax examples, and even provides conversion utilities. This adds significant value beyond the bare schema.

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's purpose as 'Evaluate mathematical expressions using a scientific calculator' with a specific verb ('evaluate') and resource ('mathematical expressions'), distinguishing it from sibling tools like generate_qr_code, roll_dice, and web_search which have completely different domains.

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 usage through the extensive list of supported operations and examples, suggesting this tool is for mathematical evaluation. However, it doesn't explicitly state when to use this versus alternatives or provide any exclusion criteria, leaving the context somewhat implied rather than clearly defined.

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/nilay320/MCP-Session-Code'

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