profitability-market

calculate_net_margin

Read-onlyIdempotent

Calculate net margin: net income divided by net sales — the share of every revenue pound/dollar that reaches the bottom line. Formula: Net Margin = Net Income / Net Sales. WHEN TO USE: Use for the all-in profitability picture after operating costs, interest, tax and other items. WHEN NOT TO USE: Do NOT use alone — net margin is affected by capital structure and tax; compare alongside gross and operating margins. BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero or non-finite inputs returns an explicit error instead of a number. RETURNS: JSON object { net_margin: decimal (e.g. 0.12 = 12%), net_margin_pct: number (e.g. 12.0), inputs }. PARAMETERS: net_income (required): Net income after tax, e.g. 120000. May be negative. net_sales (required): Net sales / revenue, e.g. 1000000. Must be > 0.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`net_sales`	Yes	Net sales / revenue, e.g. 1000000. Must be > 0.
`net_income`	Yes	Net income after tax, e.g. 120000. May be negative.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description adds concrete behavioral details: pure deterministic calculation, no side effects, no network/storage access, identical inputs give identical outputs, and division-by-zero/non-finite inputs return an explicit error. This is valuable operational context an agent cannot infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured with clear sections (formula, when to use, when not to use, behavior, returns, parameters). Despite its length, every sentence carries operational value, and the core purpose is front-loaded.

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?

For a simple pure-calculator tool with no output schema, the description fully covers inputs, outputs, error behavior, and usage boundaries. An agent has all necessary information to select and invoke this tool correctly.

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 description closely mirrors the schema for net_income and net_sales, adding no meaning beyond what the schema already provides. The formula context is helpful but does not materially change parameter understanding, so the baseline 3 applies.

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 specific verb ('Calculate'), the exact resource ('net margin'), and the formula (Net Income / Net Sales), defining the all-in profitability picture. This distinguishes it clearly from sibling tools like calculate_gross_margin and calculate_operating_margin even without comparing schemas.

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 description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It directs agents to compare alongside gross and operating margins, clearly preventing misuse in isolation and distinguishing this from related ratio tools.

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

All profitability-market tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool calculates a distinct financial metric with its own formula, inputs, and output. Even similarly named return-on-capital tools (ROA, ROE, ROCE, ROIC) are clearly differentiated by their denominators and described use cases.

Naming Consistency5/5

All 12 tools follow the exact same calculate_<metric_name> snake_case pattern. The verb is consistent and metric names map directly to the formulas, making the set highly predictable.

Tool Count5/5

Twelve tools is a well-scoped size for a financial ratio calculator covering profitability, return, valuation, and dividend metrics. Each tool addresses a distinct calculation and none feel redundant or unnecessary.

Completeness4/5

The tool surface covers core profitability margins, return ratios, EPS, dividend yield, payout ratio, P/E, and P/B. Minor gaps exist such as price-to-sales, EV/EBITDA, or EBITDA margin, but the primary domain of profitability and market valuation is well represented.

Resources

Need Help?