drasticstatic 工作副本 — 由 Fortuna 交易系统 使用。这是一个从 verygoodplugins/robinhood-mcp 的本地克隆创建的独立仓库。上游仓库被追踪为远程仓库以供自愿对比 — 更改在应用前会经过审查。
# Check for upstream updates (review before applying) git fetch upstream && git log upstream/main --oneline
一个用于 Robinhood 投资组合研究的只读 MCP 服务器。封装了 robin_stocks，让 AI 助手能够访问您的投资组合数据进行分析。
⚠️ 仅限研究工具 - 此服务器提供只读访问权限。不提供任何交易功能。
⚠️ 非官方 API - 使用 robin_stocks 非官方 API。可能会在不另行通知的情况下失效。使用风险自负。
连接后，您可以与 Claude 进行关于您投资组合的自然对话：
“帮我检查一下我的投资组合健康状况。我的总价值是多少，行业集中度如何，有哪些持仓涨跌幅较大？”
Claude 将提取您的持仓，计算行业敞口，识别表现最好和最差的资产，并标记任何集中度风险。
“我正在考虑增加 NVDA 的持仓。请向我展示其基本面、近期新闻、分析师评级以及过去一年的表现。”
获取综合研究，在一次回复中结合价格历史、市盈率、财报日期和分析师情绪。
“比较我投资组合中的邮轮公司 - 并排展示 CCL、RCL 和 NCLH 的市盈率、市值和年初至今的表现。”
快速评估类似持仓以识别相对价值。
“我今年收到了哪些股息？我的哪些持仓支付股息，它们的收益率是多少？”
追踪您的被动收入并识别投资组合中的股息机会。
“我对能源行业的敞口是多少？我在前 5 大持仓中的集中度如何？”
分析行业集中度并识别可能超配的持仓。
“我的哪些持仓在未来两周内有财报发布？”
通过个性化日历提前应对财报波动。
“分析我的投资组合回报。是什么在驱动我的收益和亏损？”
了解哪些持仓对您的业绩贡献最大。
“提取我自选列表中所有股票的报价和基本面。现在有哪些看起来很有趣？”
批量研究您正在追踪的股票。
Related MCP server: Public.com MCP Server
pip install robinhood-mcp或者直接使用 uvx 运行：
uvx robinhood-mcpexport ROBINHOOD_USERNAME="your_email"
export ROBINHOOD_PASSWORD="your_password"
export ROBINHOOD_TOTP_SECRET="your_2fa_secret" # Only if you use authenticator app注意： 如果您在 Robinhood 上使用 Face ID、Touch ID 或密码登录（没有身份验证器应用），则不需要 ROBINHOOD_TOTP_SECRET。
添加到 ~/Library/Application Support/Claude/claude_desktop_config.json：
{
"mcpServers": {
"robinhood": {
"command": "uvx",
"args": ["robinhood-mcp"],
"env": {
"ROBINHOOD_USERNAME": "your_email",
"ROBINHOOD_PASSWORD": "your_password"
}
}
}
}claude mcp add robinhood -- uvx robinhood-mcp工具 | 描述 |
| 投资组合价值、权益、购买力、日内变动 |
| 所有持仓的成本基础、当前价值、盈亏 |
| 按代码查询单个持仓的份额、价值和盈亏 |
| 您自选列表中的股票 |
| 实时价格、买入/卖出价、成交量 |
| 市盈率、市值、股息收益率、52 周区间 |
| OHLCV 价格历史（日/周/月/年） |
| 某代码的近期新闻文章 |
| 财报日期、每股收益预测、实际值 |
| 分析师买入/持有/卖出评级 |
| 股息支付历史 |
| 当前期权持仓 |
| 按名称或代码搜索股票 |
简单查询：
“我现在的投资组合价值多少？”
“按价值展示我前 5 大持仓”
“我已经持有 HIMS 了吗？我目前的持仓是多少？”
“获取 AAPL 的报价”
对于单代码投资组合问题，优先使用 robinhood_get_position 而不是 robinhood_get_positions。单代码工具避免了重建所有持仓，对于“我应该加仓 HIMS 吗？”这类问题速度快得多。
分析请求：
“比较 GOOGL 和 META 的基本面”
“我的哪些股票交易价格低于其 52 周平均水平？”
“展示 TSLA 过去一年的价格走势图”
“我表现最好的股票是什么？最差的是什么？”
研究工作流：
“我想了解邮轮行业。提取 CCL、RCL 和 NCLH 的数据 - 比较它们的基本面和近期表现。”
“查找我投资组合中市盈率低于 15 且盈利增长为正的股票”
“我在几个持仓上亏损严重。展示我表现最差的持仓的基本面和新闻，以帮助我决定是持有还是止损。”
只读：无法下单交易、修改自选列表或更改账户设置
非官方 API：Robinhood 可能随时更改其 API，导致功能失效
无实时流：报价是即时点位，而非实时推送
会话过期：您可能需要定期重新验证
速率限制：高频使用可能会触发 Robinhood 的速率限制
凭据仅在本地用于与 Robinhood 进行身份验证
会话令牌由 robin_stocks 缓存在 ~/.tokens/robinhood.pickle 中
切勿提交您的 .env 文件或泄露凭据
此工具无法执行交易 - 设计上即为只读
git clone https://github.com/verygoodplugins/robinhood-mcp.git
cd robinhood-mcp
pip install -e ".[dev]"
# Lint
ruff check . && ruff format --check .
# Test
pytest
# Run locally
robinhood-mcp“Not logged in”（未登录）错误：
验证您的用户名和密码是否正确
如果您使用带有身份验证器应用的 2FA，则需要 ROBINHOOD_TOTP_SECRET
尝试通过 Robinhood 应用登录以确保您的账户未被锁定
“Non-base32 digit found”（发现非 base32 数字）错误：
您的 TOTP 密钥包含无效字符
密钥应仅包含字母 A-Z 和数字 2-7
如果您不使用身份验证器应用，请完全删除 ROBINHOOD_TOTP_SECRET
速率限制：
robin_stocks 没有内置速率限制
如果您达到速率限制，请等待几分钟后再重试
MIT
此工具仅用于教育和研究目的。它使用可能随时失效的非官方 API。作者不对任何账户限制、数据不准确或财务损失负责。
本项目与 Robinhood Markets, Inc. 无关联、无背书，也无任何连接。
设置一个 cron 任务以获取每日投资组合简报：
# ~/.claude/commands/portfolio-review.md
---
description: "Daily portfolio health check"
---
Using the robinhood MCP tools:
1. Get my current portfolio value and day change
2. Identify my top 3 gainers and top 3 losers today
3. Flag any positions that are down more than 20% from cost basis
4. Check if any holdings have earnings in the next 7 days
5. Give me a 2-3 sentence summary I can read with my morning coffee每日运行：
# Add to crontab -e
0 7 * * 1-5 cd ~/Projects && claude -p "/portfolio-review" --dangerously-skip-permissions >> ~/portfolio-reports/$(date +\%Y-\%m-\%d).md# ~/.claude/commands/weekly-research.md
---
description: "Weekly deep dive on portfolio"
---
For each of my top 10 holdings by value:
1. Pull current fundamentals and compare to sector averages
2. Get recent news and analyst rating changes
3. Flag any significant changes from last week
4. Identify 2-3 stocks from my watchlist that might be worth adding
Format as a markdown report I can review on the weekend.由 Jack Arturo 在 Very Good Plugins 倾情打造。
由 robin_stocks 和 FastMCP 提供支持。
Get all dividend payments received.
Returns list of dividend payments with amount, payable date, record date, and instrument details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only lists output fields without disclosing behavioral traits like authentication needs, rate limits, or side effects. Minimal transparency beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the verb and resource, second lists output fields. No redundant words, front-loaded, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema present, the description is largely sufficient. However, it lacks mention of pagination or any constraints, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so the baseline is 4. Schema coverage is 100% (vacuously), and the description adds no param info but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specific resource 'dividend payments received', distinguishing it from sibling tools like robinhood_get_earnings and robinhood_get_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites. The description only states what it does without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get earnings data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the basic purpose. It does not mention whether results are filtered by date, whether it returns future or past earnings, or any side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but could incorporate more useful information within its brevity without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description does not need to detail return values. However, it lacks context about the nature of earnings data (e.g., quarterly vs annual) and any filtering capabilities, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'symbol', with a clear description 'Stock ticker symbol'. The description adds no further meaning beyond the schema, achieving baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'earnings data' for a stock, distinguishing from siblings like get_quote or get_news. However, it does not specify what aspects of earnings (e.g., revenue, EPS, date) are included, which could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_fundamentals which might also include earnings. No exclusions or context provided, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fundamental data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'get fundamental data', not disclosing read-only nature, authentication needs, or any side effects. Vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words, but lacks structure or front-loading of critical info. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema present, the description is minimally adequate but omits behavior details. Could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'symbol' is described in the schema as 'Stock ticker symbol'. The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'fundamental data for a stock', distinguishing it from siblings like get_quote or get_ratings. However, it could be more specific about what fundamental data includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of siblings like robinhood_get_earnings or robinhood_get_dividends, which also provide fundamental data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol | |
| interval | No | Time interval (5minute, 10minute, hour, day, week) | day |
| span | No | Time span (day, week, month, 3month, year, 5year) | month |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It only states the tool retrieves historical data, but does not disclose key traits such as output format (OHLCV? adjusted?), rate limits, or data frequency nuances. This is insufficient for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) with no fluff. However, it could benefit from slightly more detail without sacrificing brevity, such as mentioning supported intervals or output type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. However, it lacks context about behavior like data granularity or historical range limitations, making it minimally adequate for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the schema already defines parameters (symbol, interval, span). The description adds no additional meaning beyond 'historical price data', yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'historical price data for a stock,' effectively distinguishing it from siblings like robinhood_get_quote (current price) and robinhood_get_fundamentals. However, it lacks explicit mention of time-range parameters that further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_quote for current price, get_dividends for dividend history). The description does not state prerequisites or typical use cases, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent news articles for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action, omitting details like rate limits, pagination, or the meaning of 'recent'. The read-only nature is implied but not confirmed, and potential limitations are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. Every word serves a purpose, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema exists), the description is adequate but leaves gaps: no mention of output format, number of articles, or time range. The existence of an output schema partially compensates, but behavioral context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter 'symbol' with description 'Stock ticker symbol'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent news articles for a stock' clearly states the verb (get), resource (news articles), and scope (recent, for a stock). It effectively distinguishes from sibling tools that deal with dividends, earnings, fundamentals, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like robinhood_get_ratings or robinhood_get_fundamentals. The purpose is self-evident, but the description does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all current options positions (read-only).
Returns list of options positions with chain symbol, type, strike price, expiration, and quantity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that the operation is 'read-only', which adds transparency. However, it does not disclose other behavioral traits such as pagination, rate limits, or authentication requirements beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loaded with the core action. Every sentence adds value without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the essential information. It could optionally mention that it returns positions for the authenticated user, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no parameter detail, but baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all current options positions (read-only)' and lists the returned fields. It effectively distinguishes from sibling tools like robinhood_get_positions by specifying 'options positions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. The name implies it is for options positions, but no alternatives are mentioned or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current portfolio value and performance metrics.
Returns portfolio profile with equity, extended hours equity, withdrawable amount, and other account details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation by stating it returns data, but does not explicitly disclose safety, authentication requirements, or rate limits. The lack of annotations places the burden on the description, which does not fully address these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only two sentences with no fluff. The first sentence states the purpose, and the second elaborates on return fields. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, output schema exists), the description is mostly complete. It lists key return fields. A minor improvement could mention that the data reflects current market conditions, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is trivially 100%. The description adds value by explaining what the tool returns (equity, extended hours equity, etc.) without repeating schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets portfolio value and performance metrics, listing specific fields like equity and withdrawable amount. It distinguishes itself from sibling tools like robinhood_get_dividends or robinhood_get_positions by focusing on the overall portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but given its simple nature (no parameters), usage is straightforward. Some mention of context (e.g., 'Use this to check your overall account summary') would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one current stock position with a faster single-symbol lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol (e.g., "HIMS", "AAPL") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description bears full burden. It describes a read operation but omits details like data freshness ('current'), authentication requirements, or rate limits. Minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and differentiator. No unnecessary words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 1-parameter tool with output schema, description is minimally adequate but lacks context on what 'current' means (e.g., real-time vs delayed) and any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description for 'symbol'. Description adds no additional meaning beyond schema, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves one current stock position, and 'faster single-symbol lookup' distinguishes it from the plural sibling tool 'robinhood_get_positions' which likely handles multiple symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for single-symbol lookups and suggests speed advantage, but does not explicitly exclude use cases or mention when to prefer the sibling tool for multiple symbols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all current stock positions with details.
Returns a dict mapping stock symbols to position details including price, quantity, average buy price, equity, and percent change.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It describes output structure but does not disclose behavioral traits like authentication requirements, data freshness, or that it is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second describes return format, third lists included details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, description adequately explains what the tool does and what it returns. Could mention that it pertains to the authenticated user, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, and description confirms it retrieves all positions. No additional meaning needed beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets all current stock positions with details, using specific verb 'get' and resource 'all current stock positions'. Distinguishes from sibling robinhood_get_position which gets a single position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies 'all current stock positions', providing context for when to use it. No explicit exclusions or alternatives, but sibling names imply it's the broadest retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time quote for a stock symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol (e.g., "AAPL", "TSLA") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does not mention any behavioral traits such as data freshness (e.g., 'real-time' is claimed but not qualified), limitations, or required permissions. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. However, it could be expanded slightly to include context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is minimally adequate. However, given the number of sibling tools, the agent could benefit from knowing that this is the primary quote endpoint or what specific fields the output contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'symbol' parameter is described as 'Stock ticker symbol'). The description adds no additional meaning beyond the schema, which is adequate for a single, well-known parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a real-time quote for a given stock symbol, using a specific verb ('get') and resource ('real-time quote'). It is distinct from sibling tools like robinhood_get_dividends or robinhood_get_historicals, which cover different financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. Given the set of similar data retrieval tools, explicit conditions or alternatives (e.g., 'for price data use this, for financial statements use fundamentals') are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analyst ratings summary for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description offers no behavioral details beyond the implied read operation. Does not mention authentication requirements, error handling for invalid symbols, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Efficient for a tool with one parameter, though it could be slightly more informative without much cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a simple input, the description is adequate but minimal. Does not leverage the presence of siblings to clarify positioning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'symbol', which already has a clear description. The tool description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Get'), the resource ('analyst ratings summary'), and the target ('a stock'). Distinguishes from sibling tools like robinhood_get_news or robinhood_get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool versus alternatives. Does not explain scenarios where ratings would be appropriate or when to use other tools like get_quote or get_fundamentals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stocks in a watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Watchlist name (default: "Default") | Default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It states only 'Get stocks in a watchlist,' which is a read operation, but does not confirm idempotency, authentication needs, or any side effects. The minimal description fails to provide safety guarantees beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, which is efficient and front-loaded. However, it could include a brief note on what the output contains or the parameter's impact without becoming verbose, making it slightly under-informative for a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description is minimally adequate. It does not mention the output format (though it can be inferred from the output schema) and lacks integration with sibling tools, leaving room for improvement in guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter, including a default value. The description does not add any meaning beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'stocks in a watchlist,' which distinguishes it from sibling tools like robinhood_get_portfolio or robinhood_get_positions. However, it lacks specificity about what details of the stocks are returned (e.g., symbols only or full data), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like robinhood_get_positions or robinhood_get_portfolio. The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stock symbols by company name or ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (company name or partial ticker) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose behaviors such as case sensitivity, exact vs. partial matching, or output format beyond the schema. Minimal detail limits an agent's ability to anticipate results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is easy to parse but could be more informative while remaining concise. A bit underspecified but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so complexity is low. The description adequately states the core function but omits behavioral traits like rate limits or read-only status. For a simple search tool, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'query' with a description matching the tool description. Since coverage is 100%, the baseline is 3. The description adds no additional meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for stock symbols by company name or ticker' clearly states the verb 'Search', the resource 'stock symbols', and the method (by name or ticker). It is distinct from sibling tools which focus on dividends, earnings, quotes, etc., avoiding confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding symbols but provides no explicit guidance on when to use this tool versus alternatives (e.g., to get quotes or fundamentals after searching). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2robinhood_get_dividendsrobinhood_get_earningsrobinhood_get_fundamentalsrobinhood_get_historicalsrobinhood_get_newsrobinhood_get_options_positionsrobinhood_get_portfoliorobinhood_get_positionrobinhood_get_positionsrobinhood_get_quoterobinhood_get_ratingsrobinhood_get_watchlistrobinhood_search_symbolsScored across 13 tools
Each tool targets a distinct data type (dividends, earnings, fundamentals, etc.) with clear boundaries. The only potential overlap is between get_position and get_positions, but they are differentiated by single vs. all symbols.
All tools follow a uniform 'robinhood_verb_noun' pattern, using snake_case and descriptive verbs (get, search). No mixing of styles or vague names.
13 tools is well-suited for a data-heavy financial service, covering a broad range of endpoints without being overwhelming. The count feels neither sparse nor excessive.
The tool set comprehensively covers read-only data retrieval (quotes, positions, dividends, earnings, news, etc.), but lacks write operations (e.g., placing orders) which might be expected from a brokerage service. Minor gap for transactional use cases.
Read-only MCP server for Robinhood Chain token discovery, research, and due diligence via GMGN.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Read-only MCP server exposing a user ORANO library to their own AI agent.
MCP server exposing the Backtest360 engine API as tools for AI agents.
