Provides read-only access to Robinhood portfolio data, including positions, watchlists, quotes, fundamentals, historicals, news, earnings, dividends, and options positions, enabling AI assistants to analyze holdings and research stocks.
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 health check"
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.
drasticstatic working copy — Used by the Fortuna trading system. This is an independent repo created from a local clone of verygoodplugins/robinhood-mcp. Upstream is tracked as a remote for voluntary comparison — changes are reviewed before applying.
# Check for upstream updates (review before applying) git fetch upstream && git log upstream/main --oneline
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.
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.
"Pull quotes and fundamentals for everything in my watchlist. Which ones look interesting right now?"
Bulk research stocks you're tracking.
Related MCP server: Public.com MCP Server
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" # Only if you use authenticator appNote: If you use Face ID, Touch ID, or passcode login on Robinhood (no authenticator app), you don't need ROBINHOOD_TOTP_SECRET.
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"
}
}
}
}claude mcp add robinhood -- uvx robinhood-mcpTool | Description |
| 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 |
| Search stocks by name or ticker |
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?"
"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
"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, so description must carry full burden. It states it returns dividend payments, implying a read operation, but lacks details like pagination, time range, or whether it requires specific account permissions.
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 concise sentences, no extraneous text. 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?
With no parameters and an existing output schema, the description is adequate but lacks depth. It doesn't mention if results are filterable or if there's a limit, which could be important for an agent managing large portfolios.
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?
No parameters; schema coverage is 100%. Per rules, baseline is 4. Description adds no parameter info but none is needed.
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 'Get all dividend payments received' and lists returned fields (amount, payable date, record date, instrument details). It is specific and distinct from sibling tools like robinhood_get_earnings.
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 (e.g., robinhood_get_portfolio for positions, or robinhood_get_historicals for price history). No context on prerequisites or limitations.
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?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, what data is returned (e.g., quarterly earnings, surprise factors), or any constraints like date range. A minimal statement like 'Returns earnings per share and revenue for recent quarters' would add transparency.
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, concise sentence that is front-loaded and free of unnecessary words. Every word 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 the presence of an output schema (not shown), the description does not need to detail return values. However, it lacks context about how earnings data relates to sibling tools and does not compensate for missing annotations. It is minimally complete for a simple lookup tool but feels lacking in a rich API with many similar endpoints.
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% coverage for the single 'symbol' parameter, with a standard description. The tool description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter adequately.
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 'Get earnings data for a stock,' which specifies the action (get), resource (earnings data), and scope (for a stock). It effectively distinguishes from sibling tools like robinhood_get_dividends or robinhood_get_fundamentals by naming a distinct data type.
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. With many sibling tools covering related financial data, the description should indicate contexts or criteria for selecting earnings data (e.g., 'Use for company earnings reports; for broader financial metrics, see get_fundamentals').
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; description lacks behavioral details such as read-only nature, rate limits, or authentication needs. For a data retrieval tool, more transparency is expected.
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—efficient but under-specified. It lacks structure or additional detail that could aid the agent.
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 should at least hint at what fundamental data includes (e.g., metrics). No annotations mean the description must provide more context, which it fails to do.
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% with the single parameter 'symbol' already described in the schema. The description adds no additional meaning beyond the schema.
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 fundamental data for a stock. The verb 'get' and resource 'fundamental data' are specific, but 'fundamental data' is vague and does not distinguish from siblings like ratings or earnings.
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 robinhood_get_ratings or robinhood_get_earnings. No when-not-to-use or prerequisite information.
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?
With no annotations, the description carries full burden but only states 'get historical price data', implying a read operation. It does not disclose any behavioral traits such as authentication requirements, data adjustments, or limitations like rate limits or data range. The minimal description leaves 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?
The description is a single, concise sentence with no unnecessary words. It is appropriately front-loaded and efficient for a simple tool.
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 an output schema, so return values are covered. However, the description omits mention of default parameter values (interval='day', span='month') and any usage constraints. While functional, it is minimally complete and could provide more context without being verbose.
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, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, earning the 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 tool gets historical price data for a stock, which is a specific verb+resource. However, it does not differentiate from sibling tools like 'get_quote' (current price) or 'get_fundamentals' (financial data), missing an opportunity to clarify its unique purpose.
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. There is no mention of when not to use it, required context, or alternative tools like 'get_quote' for current data or 'search_symbols' for lookup.
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?
No behavioral traits are disclosed beyond the basic purpose. No annotations are provided, so the description carries full burden but lacks details on API behavior, rate limits, or what type of news is returned.
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 concise sentence with no extraneous words. However, it is almost too minimal, lacking useful context that could be added without bloat.
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 one parameter, no annotations, and an output schema exists, the description is adequate but does not explain the nature of the news, recency, or source. 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?
Schema description coverage is 100% because the only parameter 'symbol' has a description. The description adds no additional meaning or context beyond the schema, resulting in 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 tool retrieves recent news articles for a stock. The verb 'Get' and resource 'recent news articles' are specific, and it distinguishes from sibling tools like robinhood_get_earnings and 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 this tool versus siblings such as robinhood_get_ratings or robinhood_get_fundamentals. There is no mention of alternative tools or conditions for use.
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?
No annotations are provided, so the description carries the full burden. It declares read-only and lists return fields. However, it does not mention limits, pagination, or prerequisites.
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 with clear structure: action then return details. No unnecessary 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?
With 0 parameters and output schema existing, description covers core purpose and return fields. Could mention scope (all under account) or if expired included, but not critical.
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 0 parameters, baseline is 4. Description does not add parameter info because none exist.
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 all current options positions, is read-only, and lists returned fields. It distinguishes from siblings like robinhood_get_positions (likely stock positions) and robinhood_get_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?
The description implies usage for options positions but does not explicitly compare with alternatives. Sibling names are clear, so context is adequate but lacks exclusions.
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 are provided, so the description carries the full burden. It lists return values (equity, extended hours equity, withdrawable amount) but does not disclose other behavioral traits like authentication requirements or rate limits. For a read-only tool, this is acceptable but not exhaustive.
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 concise sentences: first states the purpose, second details the returned data. No redundant information; every sentence 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 the tool has no parameters and an output schema exists, the description is complete. It clearly explains what the tool does and what it returns, covering all necessary context for agent selection.
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?
With zero parameters, there is no need to explain parameter meaning. The description adds value by specifying the output contents, which is not covered by the schema alone.
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 uses a specific verb ('Get') and resource ('current portfolio value and performance metrics'), clearly distinguishing it from sibling tools that retrieve other data types like dividends or earnings.
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 obtaining portfolio metrics, but lacks explicit guidance on when not to use or how it compares to siblings. However, given the tool's singular focus, the context is clear.
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?
With no annotations provided, the description does not disclose behavioral traits such as idempotency, error handling, authentication needs, or what 'current' means. The output schema may cover return format, but safety and side effects are unaddressed.
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 concise sentence, but it could benefit from minor restructuring (e.g., front-loading the purpose and adding a brief usage note). It is efficient but slightly under-specified.
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 presence of an output schema and one simple parameter, the description is minimally adequate. However, it omits context on when the 'faster' lookup applies and how it differs from the plural variant, leaving some gaps for an AI agent.
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 the 'symbol' parameter with examples. The description adds no extra meaning beyond the schema, earning 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', the resource 'one current stock position', and highlights 'faster single-symbol lookup', effectively distinguishing it from the sibling tool 'robinhood_get_positions' which retrieves multiple 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 implies use for a single symbol lookup with speed advantage but lacks explicit guidance on when not to use or direct comparison to alternatives like 'robinhood_get_positions'.
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, the description states it 'returns a dict mapping stock symbols to position details,' which implies a read operation. However, it does not explicitly confirm safety (read-only, no side effects) or address data freshness, pagination, or required authentication.
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 consists of two concise sentences: the first states the tool's purpose, and the second details the return format. No redundant or extraneous information, making it highly 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 existing output schema, the description adequately covers what the tool does and what it returns, including specific fields. It lacks an explicit statement of read-only behavior, but this is minor given the nature of a 'get' operation. Overall, it is sufficiently 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 has no parameters (0 params, 100% coverage). The description does not need to add parameter details. Baseline for 0 params is 4, and the description appropriately omits extra parameter information.
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 'Get all current stock positions with details,' specifying the verb ('Get') and resource ('stock positions'). It distinguishes from the sibling 'robinhood_get_position' by implying plural (all positions) and mentions the return format (dict mapping symbols to details).
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 'robinhood_get_position' or 'robinhood_get_portfolio'. The description does not provide context, preconditions, or exclusions.
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?
No annotations are provided, so the description carries full burden. It states 'real-time quote' but doesn't disclose potential delay, market hours, or authentication needs. Adequate but minimal.
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 with no wasted words. Could be more informative without losing conciseness, but it is well-structured for its length.
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 presence of an output schema, the description adequately indicates the tool's purpose. However, it lacks context on usage constraints or data updates, making it marginally 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 100% description coverage for the single parameter. 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 clearly states the verb 'Get', the resource 'real-time quote', and the input 'stock symbol'. It is specific and distinguishes from sibling tools (e.g., robinhood_get_dividends, robinhood_get_earnings).
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, nor any prerequisites or exclusions. The description is too brief to guide selection among similar quote-related tools.
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 are provided, so the description must bear the full burden of behavioral disclosure. It merely states it gets a summary, but does not describe what the summary includes (e.g., rating counts, target price), data freshness, 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?
The description is a single, front-loaded sentence with no wasted words, making it efficient 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?
The tool is simple with one parameter and an output schema exists, so the description doesn't need to detail return values. However, it lacks some behavioral context that would be helpful, such as whether the summary is for the current day or a historical period.
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 single parameter 'symbol', which is adequately described as 'Stock ticker symbol'. The description adds no further meaning, so 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 the verb 'Get', the resource 'analyst ratings summary', and the scope 'for a stock', effectively distinguishing it from sibling tools like robinhood_get_dividends or robinhood_get_earnings.
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 offers no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. For example, it doesn't specify if this is for a single symbol or if it provides consensus ratings.
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?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get stocks in a watchlist' without indicating whether it is read-only, any side effects, permission requirements, or error cases. The description lacks behavioral context.
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 short and front-loaded, but it could include more useful information without much additional length. Currently it is underinformative.
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 output schema exists (not shown), return values are covered. However, the description lacks context about default behavior, scope (e.g., only returns symbols or full details), and whether it can be used without a watchlist name. It is minimally viable.
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 the single parameter 'name', including default value. The description adds no additional semantics beyond the schema.
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 'stocks in a watchlist'. It distinguishes from siblings which target different data types (dividends, earnings, etc.). However, it does not explicitly mention that it returns the list of stock symbols or details for a named watchlist, leaving slight ambiguity.
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 or how to use this tool versus alternatives like search_symbols or get_positions. There is no mention of prerequisites (e.g., user must have a watchlist) or context for expected usage.
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 carries full burden. It implies read-only search behavior but does not explicitly state if it is safe or mention 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 with no padding, directly communicates the tool's function.
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 search tool with one parameter and an output schema, the description is largely complete. It could mention that the output is a list, but the output schema likely covers that.
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% and the schema parameter description already explains the query. The tool description adds minimal extra meaning beyond restating the schema.
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 'search' and resource 'stock symbols' with the method 'by company name or ticker'. This distinguishes it from sibling get_* tools that retrieve specific 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?
No guidance on when to use this tool versus alternatives, such as suggesting to use it for symbol discovery then other tools for details.
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_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_symbolsEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/drasticstatic/robinhood-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
