This server provides read-only access to Robinhood account data for AI-assisted portfolio research and analysis.
Portfolio & Positions
Get current portfolio value, equity, buying power, and performance metrics
View all stock holdings with cost basis, current value, P&L, and percent change
Monitor options positions (chain symbol, type, strike, expiration, quantity)
Review dividend payment history (amounts, payable dates)
Stock Research
Real-time quotes: Last trade price, bid/ask spread, trading volume, and status
Fundamental data: P/E ratio, market cap, dividend yield, 52-week range
Historical prices: OHLCV data with configurable intervals (5min–weekly) and spans (day–5 years)
News: Recent articles with title, source, URL, and publication date
Earnings: EPS estimates vs. actuals, report dates
Analyst ratings: Buy/hold/sell counts and recommendation summaries
Symbol search: Find stocks by company name or partial ticker
Analysis & Automation
Compare multiple stocks side-by-side on fundamentals and performance
Identify top performers/losers, analyze sector concentration and risk exposure
Access and research stocks in your Robinhood watchlists
Enable automated daily portfolio reviews and weekly research digests via Claude integration
Provides read-only access to Robinhood portfolio data, including portfolio metrics, stock positions with P&L, watchlists, real-time quotes, fundamentals, historical price data, news, earnings, analyst ratings, dividends, and options positions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Robinhood MCP show me my portfolio value and top positions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only MCP server for Robinhood portfolio research. Wraps robin_stocks to give AI assistants access to your portfolio data for analysis.
⚠️ Research Tool Only - This server provides read-only access. No trading functionality is exposed.
⚠️ Unofficial API - Uses robin_stocks unofficial API. May break without notice. Use at your own risk.
This demo uses simulated account data and a generic assistant interface. It shows read-only research workflows only; it does not show real credentials, real holdings, professional advice, or trade execution.
Related MCP server: IB Async MCP Server
Once connected, you can have natural conversations with Claude about your portfolio:
"Give me a health check on my portfolio. What's my total value, sector concentration, and any positions that are significantly up or down?"
Claude will pull your positions, calculate sector exposure, identify your best and worst performers, and flag any concentration risks.
"I'm thinking about adding to my NVDA position. Show me the fundamentals, recent news, analyst ratings, and how it's performed over the past year."
Get comprehensive research combining price history, P/E ratios, earnings dates, and analyst sentiment in one response.
"Compare the cruise lines in my portfolio - show me CCL, RCL, and NCLH side by side with their P/E ratios, market caps, and year-to-date performance."
Quickly evaluate similar holdings to identify relative value.
"What dividends have I received this year? Which of my holdings pay dividends and what are their yields?"
Track your passive income and identify dividend opportunities in your portfolio.
"What's my exposure to the energy sector? How concentrated am I in my top 5 holdings?"
Analyze sector concentration and identify positions that might be overweight.
"Which of my holdings have earnings coming up in the next two weeks?"
Stay ahead of earnings volatility with a personalized calendar.
"Break down my portfolio returns. What's driving my gains and losses?"
Understand which positions are contributing most to your performance.
"Show me my HIMS order history - every buy and sell with prices and dates."
Review the executed orders behind your positions, with per-fill detail useful for cost-basis and tax research.
"Pull quotes and fundamentals for everything in my watchlist. Which ones look interesting right now?"
Bulk research stocks you're tracking.
pip install robinhood-mcpOr run directly with uvx:
uvx robinhood-mcpexport ROBINHOOD_USERNAME="your_email"
export ROBINHOOD_PASSWORD="your_password"
export ROBINHOOD_TOTP_SECRET="your_2fa_secret" # if your account exposes TOTP (see below)
export ROBINHOOD_APPROVAL_TIMEOUT="60" # optional — seconds to wait for push approvalFor Claude Desktop and other headless deployments, you have two paths:
TOTP, if your account exposes it. Set ROBINHOOD_TOTP_SECRET to the
base32 authenticator-app secret (found at Account → Security → Two-Factor
Authentication in the Robinhood mobile app or at robinhood.com). Login is
fast, non-interactive, and survives restarts.
Push approval, otherwise. Leave ROBINHOOD_TOTP_SECRET unset. The
first tool call after a restart triggers a push notification in the
Robinhood mobile app — tap "Approve" within ROBINHOOD_APPROVAL_TIMEOUT
seconds (default 60). After that one approval, the session is cached in
~/.tokens/robinhood.pickle and reused for days/weeks, with no further
interaction until natural expiry.
Newer Robinhood accounts that use passkeys or biometric login as their primary 2FA may not surface a TOTP option in either the iOS app or web settings — push approval works fine for these accounts.
After an authentication failure the server caches the error for ~5 minutes so subsequent tool calls fail fast instead of re-blocking the MCP server while re-attempting the full login flow. Restart Claude Desktop to retry sooner.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"robinhood": {
"command": "uvx",
"args": ["robinhood-mcp"],
"env": {
"ROBINHOOD_USERNAME": "your_email",
"ROBINHOOD_PASSWORD": "your_password"
}
}
}
}If your account has TOTP enrollment available, add
"ROBINHOOD_TOTP_SECRET": "your_2fa_secret" to the env block above.
claude mcp add robinhood -- uvx robinhood-mcpTool | Description |
| Account numbers for available Robinhood accounts |
| Portfolio value, equity, buying power, day change |
| All holdings with cost basis, current value, P&L |
| One holding by ticker with quantity, value, and P&L |
| Stocks in your watchlists |
| Real-time price, bid/ask, volume |
| P/E ratio, market cap, dividend yield, 52-week range |
| OHLCV price history (day/week/month/year) |
| Recent news articles for a symbol |
| Earnings dates, EPS estimates, actuals |
| Analyst buy/hold/sell ratings |
| Dividend payment history |
| Current options positions |
| Order history (buys/sells) with per-fill detail |
| Search stocks by name or ticker |
If your Robinhood login has multiple accounts, call robinhood_get_accounts
first and pass the returned account_number to account-scoped tools. Omit
account_number to use Robinhood's default account.
Tools with optional account_number support:
robinhood_get_portfolio
robinhood_get_positions
robinhood_get_position
robinhood_get_dividends
robinhood_get_options_positions
robinhood_get_order_history
Simple queries:
"What's my portfolio worth right now?"
"Show me my top 5 holdings by value"
"Do I already own HIMS, and what's my current position?"
"List my Robinhood accounts, then show positions for my IRA account."
"Get me a quote for AAPL"
For single-symbol portfolio questions, prefer robinhood_get_position over
robinhood_get_positions. The single-symbol tool avoids rebuilding every
holding and is much faster for questions like "Should I add more HIMS?"
Analysis requests:
"Compare the fundamentals of GOOGL vs META"
"Which of my stocks are trading below their 52-week average?"
"Show me the price chart for TSLA over the past year"
"What's my best performing stock? What's my worst?"
Research workflows:
"I want to understand the cruise line industry. Pull data on CCL, RCL, and NCLH - compare their fundamentals and recent performance."
"Find stocks in my portfolio with a P/E under 15 and positive earnings growth"
"I'm down big on a few positions. Show me the fundamentals and news for my worst performers to help me decide if I should hold or cut losses."
Read-only: Cannot place trades, modify watchlists, or change account settings
Unofficial API: Robinhood may change their API at any time, breaking functionality
No real-time streaming: Quotes are point-in-time, not live feeds
Session expiry: You may need to re-authenticate periodically
Rate limits: Heavy usage may trigger Robinhood's rate limiting
Credentials are only used locally to authenticate with Robinhood
Session tokens are cached in ~/.tokens/robinhood.pickle by robin_stocks
Never commit your .env file or expose credentials
This tool cannot execute trades - it's read-only by design
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" errors:
Verify your username and password are correct
If you have 2FA with an authenticator app, you need ROBINHOOD_TOTP_SECRET
Try logging in through the Robinhood app to ensure your account isn't locked
Tool calls hang briefly then fail with "Login returned empty result": no
cached session and no ROBINHOOD_TOTP_SECRET, so the server is waiting for
you to approve a push notification in the Robinhood mobile app. Tap
"Approve" within ROBINHOOD_APPROVAL_TIMEOUT seconds (default 60) and call
the tool again — the session pickle is now cached and subsequent calls won't
prompt. If TOTP is available on your account, adding ROBINHOOD_TOTP_SECRET
removes the prompt entirely. After a failure the server caches the error for
~5 min; restart Claude Desktop to retry sooner.
"Non-base32 digit found" error:
Your TOTP secret contains invalid characters
The secret should only contain letters A-Z and digits 2-7
If you don't use an authenticator app, remove ROBINHOOD_TOTP_SECRET entirely
Rate limiting:
robin_stocks doesn't have built-in rate limiting
If you hit rate limits, wait a few minutes before retrying
MIT
This tool is for educational and research purposes only. It uses unofficial APIs that may break at any time. The authors are not responsible for any account restrictions, data inaccuracies, or financial losses.
This project is not affiliated with, endorsed by, or connected to Robinhood Markets, Inc.
Set up a cron job to get a daily portfolio briefing:
# ~/.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 coffeeRun it daily:
# 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.Built with 🧡 by Jack Arturo at Very Good Plugins.
Powered by robin_stocks and FastMCP.
AutoMem - AI memory infrastructure
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. Dates show when Glama detected each change.
v0.1.2robinhood_get_dividends1 field changedInput schema / additionalPropertiesAdded value: +falserobinhood_get_earnings2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / symbol / descriptionAdded value: +"Stock ticker symbol"robinhood_get_fundamentals2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / symbol / descriptionAdded value: +"Stock ticker symbol"robinhood_get_historicals4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / interval / descriptionAdded value: +"Time interval (5minute, 10minute, hour, day, week)"Input schema / properties / span / descriptionAdded value: +"Time span (day, week, month, 3month, year, 5year)"Input schema / properties / symbol / descriptionAdded value: +"Stock ticker symbol"robinhood_get_news2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / symbol / descriptionAdded value: +"Stock ticker symbol"robinhood_get_options_positions1 field changedInput schema / additionalPropertiesAdded value: +falserobinhood_get_portfolio1 field changedInput schema / additionalPropertiesAdded value: +falserobinhood_get_positionrobinhood_get_positions1 field changedInput schema / additionalPropertiesAdded value: +falserobinhood_get_quote2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / symbol / descriptionAdded value: +"Stock ticker symbol (e.g., \"AAPL\", \"TSLA\")"robinhood_get_ratings2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / symbol / descriptionAdded value: +"Stock ticker symbol"robinhood_get_watchlist2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / name / descriptionAdded value: +"Watchlist name (default: \"Default\")"robinhood_search_symbols2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / query / descriptionAdded value: +"Search query (company name or partial ticker)"robinhood_get_dividendsrobinhood_get_earningsrobinhood_get_fundamentalsrobinhood_get_historicalsrobinhood_get_newsrobinhood_get_options_positionsrobinhood_get_portfoliorobinhood_get_positionsrobinhood_get_quoterobinhood_get_ratingsrobinhood_get_watchlistrobinhood_search_symbolsEach tool has a distinct purpose, clearly indicated by its name and description. There is no ambiguity between tools like 'get_position' (single) and 'get_positions' (all) as they serve different use cases.
All tools follow a consistent 'robinhood_verb_noun' pattern using snake_case, making them predictable and easy to navigate.
13 tools is a well-scoped set for a financial data server, covering key areas like dividends, earnings, fundamentals, portfolio, and positions without being overwhelming.
The set covers most common read-only data needs for Robinhood users, but lacks write operations (e.g., buy/sell) and some advanced data like option chains or order history, which is acceptable for a data-focused server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
Portfolio analytics + US-equity market research for AI clients. ChatGPT deep-research compat.
9,900+ US equities, 64 years of prices, financials, technicals, and earnings. Ask in plain English.
Read-only access to your net worth, wealth percentile, projections, splits and budget.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/verygoodplugins/robinhood-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
