Finnhub

Get Price Target

get_price_target

Read-onlyIdempotent

Analyst price-target consensus for a company — high, low, mean, and median 12-month price targets, and when they were last updated. Requires your own PAID Finnhub API key with price-target access, passed as _apiKey — Pipeworx's shared key is on a lower plan and cannot reach this endpoint. For free analyst buy/hold/sell trends without a key requirement beyond the shared one, use get_recommendation_trends instead. Example: get_price_target({ symbol: "AAPL", _apiKey: "your_finnhub_key" })

Example tool call

This call uses example arguments supplied in the tool’s input schema.

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

Input Schema

Name	Required	Description	Default
`symbol`	Yes	Stock ticker symbol, e.g. "AAPL", "MSFT", "TSLA"
`_apiKey`	Yes	Your own Finnhub API key on a PAID plan that includes price-target data (finnhub.io/pricing). The shared Pipeworx key is on a lower plan and cannot reach this endpoint, unlike the other tools in this pack. Free analyst buy/hold/sell trends are available without this via get_recommendation_trends.

Output Schema

Name	Required	Description
`source`	Yes	Data source attribution
`symbol`	Yes	Stock ticker symbol
`target_low`	Yes	Lowest analyst price target
`target_high`	Yes	Highest analyst price target
`target_mean`	Yes	Mean analyst price target
`last_updated`	Yes	When the price-target consensus was last updated
`target_median`	Yes	Median analyst price target

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / _apiKey / description

Previous value: -"Finnhub API key (get one free at finnhub.io)"New value: +"Your own Finnhub API key on a PAID plan that includes price-target data (finnhub.io/pricing). The shared Pipeworx key is on a lower plan and cannot reach this endpoint, unlike the other tools in this pack. Free analyst buy/hold/sell trends are available without this via get_recommendation_trends."

AddedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds the non-obvious operational fact that the shared Pipeworx key cannot reach this endpoint because of plan tiering. That auth/plan constraint plus the routing condition is exactly the kind of context annotations cannot express, and an output schema covers return values.

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?

The output description is front-loaded, then the key constraint, then the alternative, then a single example — a sensible ordering with no filler. The only redundancy is that the paid-key caveat appears in both the description and the `_apiKey` schema description, which is defensible emphasis but slightly duplicative.

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?

For a two-parameter read tool with 100% schema coverage, an output schema, and full annotations, nothing an agent needs is missing: what it returns, what credential is required, why the shared key fails, and which sibling to use instead. Complexity is low, and the description matches it precisely.

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% and the schema already explains both `symbol` and `_apiKey` including the paid-plan caveat. The description still adds value by showing the concrete invocation form (get_price_target({ symbol: "AAPL", _apiKey: "your_finnhub_key" })), reinforcing that _apiKey is a separate caller-supplied credential rather than a server default.

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?

States a specific verb+resource ('analyst price-target consensus for a company') and enumerates the returned fields (high, low, mean, median 12-month targets, last-updated date). It explicitly names the sibling get_recommendation_trends as the different thing, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit when-not/alternative rule: if you want free analyst buy/hold/sell trends without an extra key, use get_recommendation_trends instead. It also states the hard prerequisite (own PAID Finnhub key passed as _apiKey) up front, so the agent knows when this call will fail.

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

All Finnhub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.