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

Financial Modeling Prep MCP Server

by imbenrabi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

getIndustryPESnapshot

Read-onlyIdempotent

Retrieve price-to-earnings ratios by industry and exchange for a specified date to compare valuation levels and assess how industries are priced relative to earnings.

Instructions

View price-to-earnings (P/E) ratios for different industries using the Industry P/E Snapshot API. Analyze valuation levels across various industries to understand how each is priced relative to its earnings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>"
    },
    "name": "getIndustryPESnapshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesDate (YYYY-MM-DD)
exchangeNoExchange (e.g., NASDAQ)
industryNoIndustry (e.g., Biotechnology)

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. 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 the safety and repeatability profile is covered. The word "snapshot" usefully signals a point-in-time result rather than a series, but the description says nothing about what the response contains, how many industries are returned, or how the date drives the snapshot.

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?

Two short sentences that front-load the verb and resource, with no filler or marketing language. The second sentence largely restates the first from an analyst's perspective, so a small amount of redundancy remains.

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 three-parameter read with full schema documentation and no output schema, the description covers the core purpose but leaves the agent guessing about required-vs-optional usage and the shape of the returned data. Adequate, but not complete enough to call without opening the schema.

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%, and all three parameters carry examples (NASDAQ, Biotechnology), so the schema does the heavy lifting. The description adds no meaning beyond that — it never mentions that date is required or that exchange and industry act as narrowing filters.

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 verb and resource (view P/E ratios for different industries) and names the underlying API, so the agent can tell it is an industry-level rather than sector-level valuation call. It stops short of naming getSectorPESnapshot or getHistoricalIndustryPE as the alternatives, so the differentiation is only implicit.

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?

"Analyze valuation levels across various industries" gives an implied analytical use case but no explicit when-to-use or when-not-to-use guidance. Nothing tells the agent to pick the historical variant for time series or the sector variant for broader groupings.

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