Skip to main content
Glama
Open-Agent-Tools

Open Stocks MCP

schwab_price_history

Retrieve historical stock price data for any symbol with customizable time periods and frequency intervals.

Instructions

Get price history for a stock symbol.

Args:
    symbol: Stock ticker symbol
    period_type: Type of period ('day', 'month', 'year', 'ytd')
    period: Number of periods
    frequency_type: Frequency type ('minute', 'daily', 'weekly', 'monthly')
    frequency: Frequency value

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYes
period_typeNoday
periodNo
frequency_typeNominute
frequencyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior2/5

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

No annotations provided, so description must bear full burden. It states a read operation but lacks details on data scope, rate limits, or authentication needs. Minimal behavioral disclosure beyond the name.

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?

Description is short: a single sentence and a bullet list of parameters. It is front-loaded and efficient, though could benefit from more structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and an output schema, the description does not explain return format, date range behavior, or Schwab specificity. It is incomplete for a tool with such complexity.

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 coverage is 0%, so description compensates with brief parameter explanations in the docstring, listing possible values for period_type and frequency_type. However, it does not explain parameter interactions or defaults 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?

Description clearly states 'Get price history for a stock symbol', which is a specific verb+resource. It briefly lists parameters but does not differentiate from sibling tools like 'price_history' or 'stock_price'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. With siblings like 'price_history' and 'stock_price', the absence of context or exclusions leaves ambiguity.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Open-Agent-Tools/open-stocks-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server