Skip to main content
Glama

profitability-market

by io.finance-tools.market

calculate_operating_margin

Read-onlyIdempotent

Calculate operating margin: operating income divided by net sales — profitability from core operations before financing and tax. Formula: Operating Margin = Operating Income / Net Sales. WHEN TO USE: Use to compare core business profitability across peers and over time, independent of capital structure. WHEN NOT TO USE: Do NOT use when one-off items distort operating income — consider normalised EBIT instead. 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 { operating_margin: decimal (e.g. 0.18 = 18%), operating_margin_pct: number (e.g. 18.0), inputs }. PARAMETERS: operating_income (required): Operating income / EBIT, e.g. 180000. May be negative. net_sales (required): Net sales / revenue, e.g. 1000000. Must be > 0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
net_salesYesNet sales / revenue, e.g. 1000000. Must be > 0.
operating_incomeYesOperating income / EBIT, e.g. 180000. May be negative.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description reinforces this by stating 'pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive.' It also adds useful edge-case behavior: division by zero or non-finite inputs returns an explicit error.

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 labeled sections (WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loads the core definition and formula. Every sentence adds operational or selection value, with no redundant filler.

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?

The description covers purpose, usage boundaries, behavioral guarantees, error handling, return shape, and parameter constraints. It is complete enough for an agent to call the tool correctly even without an output schema, and the annotations supply the remaining safety profile.

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 description coverage is 100%, so the baseline applies. The description repeats the parameter meanings and constraints (operating income may be negative, net_sales must be > 0), but adds little beyond the schema, aside from embedding them in the formula context. This meets the minimum viable bar but does not substantially augment the 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 states a specific verb and resource: 'Calculate operating margin: operating income divided by net sales,' and clarifies the financial meaning ('profitability from core operations before financing and tax'). It includes the exact formula, distinguishing it from sibling margin/ratio calculators.

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 provides explicit WHEN TO USE guidance and an explicit WHEN NOT TO USE exclusion, naming 'normalised EBIT' as the alternative when one-off items distort operating income. This is exactly the kind of routing information an agent needs to choose correctly among sibling 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 toolsInspect
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