Skip to main content
Glama
Sign In
Financial Modeling Prep MCP Server

Financial Modeling Prep MCP Server

by imbenrabi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

getHistoricalIndustryPE

Read-onlyIdempotent

Retrieve historical price-to-earnings ratios by industry to track valuation trends and analyze how market sentiment evolved over time.

Instructions

Access historical price-to-earnings (P/E) ratios by industry using the Historical Industry P/E API. Track valuation trends across various industries to understand how market sentiment and valuations have evolved over time.

Input Schema

NameRequiredDescriptionDefault
toNoEnd date (YYYY-MM-DD)
exchangeNoExchange (e.g., NASDAQ)
industryYesIndustry (e.g., Biotechnology)
from_dateNoStart date (YYYY-MM-DD)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.9.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed2 schema fields changedv2.6.10
    • removedInput schema / properties / from
      Removed value: -{
-  "description": "Start date (YYYY-MM-DD)",
-  "type": "string"
-}
    • addedInput schema / properties / from_date
      Added value: +{
+  "description": "Start date (YYYY-MM-DD)",
+  "type": "string"
+}
  3. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered. The description adds only vague trend-tracking framing and says nothing about data granularity, whether a date range defaults, or how missing industries behave — modest added value beyond the annotations.

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

Conciseness3/5

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

The first sentence is front-loaded and specific, but the second sentence ('Track valuation trends ... understand how market sentiment and valuations have evolved over time') is marketing filler that restates the same idea twice without adding operational detail.

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?

For a simple four-parameter read tool with full schema coverage and no output schema, the description is just barely adequate. It omits date-range behavior, expected granularity/frequency of returned series, and the relationship to the snapshot endpoint, which an agent calling it would benefit from knowing.

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

Parameters4/5

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

Schema coverage is 100% with per-parameter descriptions for exchange, industry, from_date and to, so the schema carries the load. The description reinforces that the primary axis is industry ('by industry'), which is useful framing but adds no syntax or default-value detail beyond the schema.

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?

States a specific verb and resource: accessing historical P/E ratios by industry, which distinguishes it from the snapshot siblings through the word 'historical'. However it never names getIndustryPESnapshot or getHistoricalSectorPE, leaving the boundary between industry-vs-sector and historical-vs-current to be inferred from the tool name alone.

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 'Track valuation trends ... over time' implies the use case is time-series valuation analysis rather than a point-in-time quote, but there is no explicit when-to-use/when-not statement and no reference to the snapshot alternative. Guidance is only implied.

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

Deploy Server

Other Tools