profitability-market

calculate_pe_ratio

Read-onlyIdempotent

Calculate the price-to-earnings (P/E) ratio: share price divided by earnings per share — how much investors pay per unit of earnings. Formula: P/E = Share Price / EPS. WHEN TO USE: Use for relative valuation against peers, sector averages, or a company’s own history. Higher P/E = market expects higher growth. WHEN NOT TO USE: Do NOT use when EPS is negative or near zero (ratio becomes meaningless), and prefer forward P/E for growth companies. 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 { pe_ratio: number (e.g. 18.5 = 18.5x), inputs }. PARAMETERS: share_price (required): Current share price in currency units, e.g. 45.00. Must be > 0. earnings_per_share (required): Earnings per share (trailing or forward), e.g. 2.43. Must be > 0 for a meaningful ratio.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`share_price`	Yes	Current share price in currency units, e.g. 45.00. Must be > 0.
`earnings_per_share`	Yes	Earnings per share (trailing or forward), e.g. 2.43. Must be > 0 for a meaningful ratio.

TDQS

A4.7/5.0

Behavior5/5

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

The description clearly states the calculation is deterministic, idempotent, non-destructive, and free of side effects, which reinforces and extends the annotations. It also discloses error behavior for division by zero or non-finite inputs, adding useful operational detail.

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-organized with labeled sections and every sentence adds substance. It covers purpose, usage, behavior, return format, and parameters without unnecessary 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?

Despite no output schema, the description explicitly defines the return shape, parameter constraints, and edge-case behavior. Everything an agent needs to invoke this tool correctly and interpret its result is present.

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 mostly repeats the same parameter descriptions, examples, and positivity constraints found in the schema. The formula and ratio interpretation add context, but little new parameter-specific meaning is provided.

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 names the exact metric, gives the formula, and explains what the ratio represents. It is clearly distinguishable from the sibling ratio calculators because it states the specific inputs and output.

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?

Explicit WHEN TO USE and WHEN NOT TO USE sections tell an agent exactly when this ratio is appropriate and when to avoid it, including the meaningful alternative of forward P/E for growth companies. This provides strong decision guidance beyond the schema.

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?