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

Financial Modeling Prep MCP Server

by imbenrabi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

getMarketRiskPremium

Read-onlyIdempotent

Retrieve market risk premium values for specific dates to assess the extra return expected from stock market investing over a risk-free investment.

Instructions

Access the market risk premium for specific dates with the FMP Market Risk Premium API. Use this key financial metric to assess the additional return expected from investing in the stock market over a risk-free investment.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "getMarketRiskPremium"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
  2. Changed1 schema field changedv1.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
  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 the safety profile is covered by structured data. The description adds a conceptual definition of the metric, which is genuinely useful context, but says nothing about the shape of the result (single value vs. time series), range, or granularity.

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 sentences, front-loaded with the resource and followed by the purpose. The wording carries mild marketing filler ('key financial metric', 'with the FMP Market Risk Premium API') that does not add decision-relevant information.

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 zero-parameter, annotated read tool, the description covers what the metric is and why it matters. It leaves open how the data is scoped/returned (single snapshot vs. historical series) and its 'specific dates' phrasing conflicts with the parameter-free schema, leaving a gap an agent cannot resolve from structured fields alone.

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?

With zero parameters the baseline is 4, but the phrase 'for specific dates' implies a date or date-range argument that the empty input schema does not expose. That mismatch creates a false expectation, so it scores below the no-param baseline despite adding conceptual meaning about the metric.

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 uses a clear verb+resource pairing ('Access the market risk premium') and identifies the underlying data source (FMP Market Risk Premium API). It does not compare against any sibling tool, though no sibling in the provided list covers this metric, so confusion risk is low.

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?

It states a use case ('assess the additional return expected from investing in the stock market over a risk-free investment'), which implies when the metric is useful. However, it offers no explicit when-to-use/when-not guidance, no alternatives (e.g., versus getTreasuryRates for the risk-free leg), and no prerequisites.

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