Skip to main content
Glama
TeleEng

math-reasoning-mcp

by TeleEng

partial_fraction_decomposition

Decomposes rational functions into partial fractions for easier integration, inverse Laplace transforms, and system analysis. Enter expression and variable to get a simplified sum of simpler fractions.

Instructions

Performs Partial Fraction Decomposition on a rational function (crucial for inverse transforms).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
variableYes
expressionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/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 names the operation and domain, without explaining input assumptions, how the decomposition is returned, or how improper/non-rational inputs are handled. There is no contradiction, but significant behavioral context is missing.

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. The parenthetical usage hint is useful and earns its place. It could be slightly more informative without losing conciseness, so it is not a perfect 5.

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?

Given that this is a simple two-parameter tool and an output schema exists, the description provides a minimally viable picture: the operation, the domain, and one key use case. However, zero parameter documentation and no guidance on edge cases or input formatting leave noticeable gaps for an agent deciding how to call it.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It never explicitly explains 'expression' or 'variable', though 'rational function' indirectly hints that 'expression' is the function to decompose. The parameter names are somewhat self-explanatory, but the description adds little value beyond them.

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 action, 'Performs Partial Fraction Decomposition on a rational function', which clearly identifies the tool's purpose. The parenthetical '(crucial for inverse transforms)' connects it to relevant siblings without confusing the core operation. It does not explicitly name a sibling alternative, so it stops short of a 5.

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 'crucial for inverse transforms' implies a use case and links it to sibling tools like inverse_laplace_transform_signal. However, it does not explicitly say when to choose this tool over alternatives, nor does it mention exclusions or prerequisites beyond the expression being a rational function.

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