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

Financial Modeling Prep MCP Server

by imbenrabi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

getCryptocurrencyBatchQuotes

Read-onlyIdempotent

Fetch live prices, market changes, and trading volumes for multiple cryptocurrencies in a single request to compare current crypto quotes.

Instructions

Access live price data for a wide range of cryptocurrencies with the FMP Real-Time Cryptocurrency Batch Quotes API. Get real-time updates on prices, market changes, and trading volumes for digital assets in a single request.

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": "getCryptocurrencyBatchQuotes"
  }
}

Input Schema

NameRequiredDescriptionDefault
shortNoGet short quotes instead of full quotes

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.3/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 without description help. The description adds useful content-level context by naming the returned fields (prices, market changes, trading volumes), but says nothing about rate limits, quote freshness/latency, or which exchanges/assets are covered despite advertising 'real-time' data.

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?

Two sentences that are front-loaded with the core purpose, but the vendor/API name ('FMP Real-Time Cryptocurrency Batch Quotes API') is filler and the second sentence largely restates the first with a slightly different field list. Tighter phrasing would earn the same information in half the space.

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, annotation-covered read tool with one optional parameter and no output schema, the description is adequate: it conveys that all crypto assets are returned in one call and what kind of data comes back. It is missing the short-vs-full quote behavior and any statement of coverage or result shape, which would matter since there is no output schema to fall back on.

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?

There is exactly one optional parameter ('short') and schema description coverage is 100%, so the schema fully documents it. The description never mentions the short/full quote distinction, meaning it adds no meaning beyond the schema; the baseline of 3 applies when the schema does the work.

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 names a specific verb+resource combination (live price data / batch quotes for cryptocurrencies) and states the scope as 'a wide range of cryptocurrencies ... in a single request', which implicitly separates it from the single-symbol getCryptocurrencyQuote and getCryptocurrencyShortQuote siblings. However, it never names those siblings explicitly, so the distinction relies on the word 'batch' in the name and the phrase 'single request'.

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?

'In a single request' for 'a wide range of cryptocurrencies' implies the batch use case, so an agent can infer this is for multi-asset snapshots rather than per-symbol lookups. There is no explicit when-to-use, when-not-to-use, or pointer to getCryptocurrencyQuote / getCryptocurrencyShortQuote for single assets, leaving routing to inference.

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