Skip to main content
Glama
stand-out-of-my-sun

Diogenes Microservice Gateway

by stand-out-of-my-sun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Shunting-Yard Algebraic Math, Financial IRR/NPV & Descriptive Stats Solver

evaluate_deterministic_math
Read-onlyIdempotent

Evaluates algebraic formulas and computes exact NPV, IRR, Kelly criterion, and descriptive statistics deterministically, avoiding LLM floating-point guesswork.

Instructions

Strict Shunting-Yard AST arithmetic parser with zero eval() or dynamic code execution: evaluates algebraic formulas and computes exact financial NPV, Newton-Raphson IRR, Kelly criterion, and dataset stats. Use when computing exact arithmetic formulas, cashflow NPV/IRR, or descriptive statistics without LLM floating-point guesswork; for running two-sample A/B hypothesis tests, use evaluate_ab_statistical_significance instead. Read-only edge call (32 KB, 60 RPM): accepts 'math_formula' ('precision_digits' defaults to '2_decimals'), uses '?demo=true' or L402 (10 sats); HTTP 400 if invalid.

Input Schema

NameRequiredDescriptionDefault
expressionYesAlgebraic or scientific formula to evaluate (e.g. '(125000 * (1 + 0.0725/12)^60) - 98450.50').
math_formulaNoAlias for expression: algebraic formula to evaluate.
precision_digitsNoDecimal rounding precision for returned numbers; defaults to '8_decimals' when omitted.

Output Schema

NameRequiredDescriptionDefault
expressionYesEvaluated mathematical expression.
exact_resultYesDeterministic floating-point result of the expression.
dataset_statisticsYesOptional count, mean, median, std_dev, min, and max when a dataset array is supplied.
financial_analysisYesOptional NPV, Newton-Raphson IRR, and Kelly fraction when financial parameters are supplied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.6.0
    • addedInput schema / properties / math_formula
      Added value: +{
+  "description": "Alias for expression: algebraic formula to evaluate.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "math_formula"
-]New value: +[
+  "expression"
+]
  2. Addedv1.3.3

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile, but the description adds substantive context beyond them: no eval() or dynamic execution, 32 KB payload ceiling, 60 RPM rate limit, demo mode and L402 payment of 10 sats, and HTTP 400 on invalid input. What it omits is return-shape detail, which the output schema supplies anyway.

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?

Capability and routing information is front-loaded and the sentences carry real content (scope, cost, limits, errors). It is dense to the point of being cramped – the rate limit, auth, and error facts are compressed into a single trailing parenthetical rather than structured separately.

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?

With rich annotations and an output schema, the description still supplies rate limits, payload cap, auth modes, and failure behavior – enough for an agent to call it correctly. The only incompleteness is the conflicting precision default, which leaves the parameter behavior ambiguous between two sources.

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%, so the baseline is 3. The description does add value by noting the 'math_formula' alias and the demo/L402 access paths, but it also states that 'precision_digits' defaults to '2_decimals' while the schema says '8_decimals' – a direct conflict that could lead an agent to miscalibrate rounding.

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?

States a specific verb and resource family (Shunting-Yard AST arithmetic evaluation) and enumerates the concrete capabilities: algebraic formulas, NPV, Newton-Raphson IRR, Kelly criterion, and descriptive stats. It explicitly separates itself from the sibling evaluate_ab_statistical_significance, so an agent can pick between them without opening either schema.

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?

The 'Use when…' clause gives the positive trigger conditions and names the alternative tool for the adjacency case (two-sample A/B tests). That is an explicit when/when-not/alternative triple.

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