Academic Writer MCP

Calculer une formule

evaluate_formula

Read-onlyIdempotent

Calculates scientific and engineering formulas from supplied values and units, solving for one unknown when needed.

Instructions

Calcule une formule avec les valeurs FOURNIES (jamais supposées), unités comprises. Exemples : formula « d = mz », values {"m": "2 мм", "z": "20"} ; ou avec une seule inconnue « d = mz », values {"d": "40 мм", "m": "2 мм"} (résolution SymPy). target_unit : « мм », « рад/с »... Écrire les multiplications explicitement (m*z). Fonctions : sin, cos, tg, sqrt, ln, lg, exp ; constante π.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "formula": "<formula>",
      "values": "<values>"
    },
    "name": "evaluate_formula"
  }
}

Input Schema

Name	Required	Description	Default
`values`	Yes
`formula`	Yes
`target_unit`	No

Output Schema

Name	Required	Description	Default
`notice`	No		Calcul fait avec les seules valeurs fournies : aucune donnée n'est supposée ni inventée.
`formula`	Yes
`unit_si`	Yes
`warnings`	No
`expression`	Yes	Expression évaluée (après résolution éventuelle).
`results_si`	Yes
`solved_for`	Yes
`target_unit`	No
`values_used`	Yes
`results_in_target`	No
`results_as_written`	Yes	Résultat avec les nombres tels que donnés (unités ignorées) : utile quand la formule est écrite pour des unités précises (n en об/мин, longueurs en мм...).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world behavior, and the description adds genuine context: the 'never assumed' invariant, SymPy-based solving for one unknown, the supported function set, and the explicit multiplication rule. It does not describe error behavior on inconsistent units or values, which is a modest gap.

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?

Front-loads the governing rule, then follows with examples and syntax notes in compact sentences. Dense but largely information-bearing; the mix of examples and constraints is slightly cluttered but nothing is gratuitous.

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?

For a three-parameter computational tool with a nested values object and an output schema, this covers syntax, units, solving mode, and function support. Minor gaps remain around conflicting or inconsistent inputs, but everything needed to invoke it correctly is present.

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?

Schema coverage is 0%, so the description must carry parameter meaning and it does: formula syntax rules (explicit multiplication, allowed functions sin/cos/tg/sqrt/ln/lg/exp and π), values as a string-valued mapping with units, and target_unit examples like « мм » and « рад/с ». This fully compensates for 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?

States a specific verb (compute) and resource (formula) with the key constraint front-loaded: values must be supplied, never assumed, units included. An agent can distinguish this from convert_units or check_consistency siblings without inspecting schemas.

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

Usage Guidelines4/5

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

Two worked examples make the usage modes explicit: full-value evaluation and solving for a single unknown with SymPy. It gives clear context for when each mode applies, though it does not name alternatives or state exclusions (e.g., when convert_units is the right sibling).

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

Deploy Server