drasticstatic Arbeitskopie — Wird vom Fortuna-Handelssystem verwendet. Dies ist ein unabhängiges Repo, das aus einem lokalen Klon von verygoodplugins/robinhood-mcp erstellt wurde. Upstream wird als Remote für freiwillige Vergleiche nachverfolgt — Änderungen werden vor der Anwendung überprüft.
# Check for upstream updates (review before applying) git fetch upstream && git log upstream/main --oneline
Ein schreibgeschützter MCP-Server für die Recherche im Robinhood-Portfolio. Er nutzt robin_stocks, um KI-Assistenten Zugriff auf Ihre Portfoliodaten zur Analyse zu geben.
⚠️ Nur Forschungstool - Dieser Server bietet nur Lesezugriff. Es sind keine Handelsfunktionen verfügbar.
⚠️ Inoffizielle API - Verwendet die inoffizielle API von robin_stocks. Kann ohne Vorankündigung ausfallen. Nutzung auf eigene Gefahr.
Sobald die Verbindung hergestellt ist, können Sie natürliche Unterhaltungen mit Claude über Ihr Portfolio führen:
"Gib mir einen Gesundheitscheck für mein Portfolio. Was ist mein Gesamtwert, meine Sektorkonzentration und gibt es Positionen, die deutlich im Plus oder Minus sind?"
Claude ruft Ihre Positionen ab, berechnet das Sektorengagement, identifiziert Ihre besten und schlechtesten Performer und weist auf Konzentrationsrisiken hin.
"Ich überlege, meine NVDA-Position aufzustocken. Zeig mir die Fundamentaldaten, aktuelle Nachrichten, Analystenbewertungen und wie sich die Aktie im letzten Jahr entwickelt hat."
Erhalten Sie umfassende Recherchen, die Kurshistorie, KGV-Verhältnisse, Gewinntermine und Analystenstimmung in einer Antwort kombinieren.
"Vergleiche die Kreuzfahrtlinien in meinem Portfolio - zeige mir CCL, RCL und NCLH nebeneinander mit ihren KGV-Verhältnissen, Marktkapitalisierungen und der Performance seit Jahresbeginn."
Bewerten Sie schnell ähnliche Bestände, um den relativen Wert zu identifizieren.
"Welche Dividenden habe ich dieses Jahr erhalten? Welche meiner Bestände zahlen Dividenden und wie hoch sind ihre Renditen?"
Verfolgen Sie Ihr passives Einkommen und identifizieren Sie Dividendenmöglichkeiten in Ihrem Portfolio.
"Wie hoch ist mein Engagement im Energiesektor? Wie stark bin ich in meinen Top-5-Beständen konzentriert?"
Analysieren Sie die Sektorkonzentration und identifizieren Sie Positionen, die möglicherweise übergewichtet sind.
"Welche meiner Bestände haben in den nächsten zwei Wochen Gewinnbekanntgaben?"
Bleiben Sie der Volatilität bei Gewinnbekanntgaben mit einem personalisierten Kalender einen Schritt voraus.
"Schlüssele meine Portfoliorenditen auf. Was treibt meine Gewinne und Verluste an?"
Verstehen Sie, welche Positionen am meisten zu Ihrer Performance beitragen.
"Rufe Kurse und Fundamentaldaten für alles auf meiner Watchlist ab. Welche sehen gerade interessant aus?"
Recherchieren Sie gesammelt Aktien, die Sie beobachten.
Related MCP server: Public.com MCP Server
pip install robinhood-mcpOder führen Sie es direkt mit uvx aus:
uvx robinhood-mcpexport ROBINHOOD_USERNAME="your_email"
export ROBINHOOD_PASSWORD="your_password"
export ROBINHOOD_TOTP_SECRET="your_2fa_secret" # Only if you use authenticator appHinweis: Wenn Sie Face ID, Touch ID oder einen Passcode-Login bei Robinhood verwenden (keine Authenticator-App), benötigen Sie ROBINHOOD_TOTP_SECRET nicht.
Hinzufügen zu ~/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 | Beschreibung |
| Portfoliowert, Eigenkapital, Kaufkraft, Tagesänderung |
| Alle Bestände mit Einstandskurs, aktuellem Wert, G&V |
| Ein Bestand nach Ticker mit Menge, Wert und G&V |
| Aktien auf Ihren Watchlists |
| Echtzeitkurs, Geld/Brief, Volumen |
| KGV, Marktkapitalisierung, Dividendenrendite, 52-Wochen-Spanne |
| OHLCV-Kurshistorie (Tag/Woche/Monat/Jahr) |
| Aktuelle Nachrichtenartikel für ein Symbol |
| Gewinntermine, EPS-Schätzungen, Ist-Werte |
| Analysten-Kauf/Halten/Verkauf-Bewertungen |
| Dividenden-Zahlungshistorie |
| Aktuelle Optionspositionen |
| Suche nach Aktien nach Name oder Ticker |
Einfache Abfragen:
"Was ist mein Portfolio gerade wert?"
"Zeig mir meine Top 5 Bestände nach Wert"
"Besitze ich bereits HIMS und was ist meine aktuelle Position?"
"Gib mir einen Kurs für AAPL"
Für Fragen zu einzelnen Symbolen im Portfolio bevorzugen Sie robinhood_get_position gegenüber robinhood_get_positions. Das Einzelsymbol-Tool vermeidet den Neuaufbau aller Bestände und ist bei Fragen wie "Sollte ich mehr HIMS hinzufügen?" viel schneller.
Analyseanfragen:
"Vergleiche die Fundamentaldaten von GOOGL vs META"
"Welche meiner Aktien handeln unter ihrem 52-Wochen-Durchschnitt?"
"Zeig mir den Kurschart für TSLA über das letzte Jahr"
"Was ist meine am besten performende Aktie? Was ist meine schlechteste?"
Recherche-Workflows:
"Ich möchte die Kreuzfahrtindustrie verstehen. Rufe Daten zu CCL, RCL und NCLH ab - vergleiche ihre Fundamentaldaten und die jüngste Performance."
"Finde Aktien in meinem Portfolio mit einem KGV unter 15 und positivem Gewinnwachstum"
"Ich bin bei einigen Positionen stark im Minus. Zeige mir die Fundamentaldaten und Nachrichten für meine schlechtesten Performer, um mir bei der Entscheidung zu helfen, ob ich halten oder Verluste begrenzen soll."
Schreibgeschützt: Kann keine Trades platzieren, Watchlists ändern oder Kontoeinstellungen anpassen
Inoffizielle API: Robinhood kann seine API jederzeit ändern, was die Funktionalität beeinträchtigen kann
Kein Echtzeit-Streaming: Kurse sind punktuelle Zeitwerte, keine Live-Feeds
Sitzungsablauf: Möglicherweise müssen Sie sich regelmäßig neu authentifizieren
Ratenbegrenzungen: Intensive Nutzung kann die Ratenbegrenzung von Robinhood auslösen
Anmeldedaten werden nur lokal zur Authentifizierung bei Robinhood verwendet
Sitzungstoken werden von robin_stocks in ~/.tokens/robinhood.pickle zwischengespeichert
Committen Sie niemals Ihre .env-Datei und geben Sie keine Anmeldedaten preis
Dieses Tool kann keine Trades ausführen - es ist konzeptionsbedingt schreibgeschützt
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"-Fehler:
Überprüfen Sie, ob Benutzername und Passwort korrekt sind
Wenn Sie 2FA mit einer Authenticator-App haben, benötigen Sie ROBINHOOD_TOTP_SECRET
Versuchen Sie, sich über die Robinhood-App anzumelden, um sicherzustellen, dass Ihr Konto nicht gesperrt ist
"Non-base32 digit found"-Fehler:
Ihr TOTP-Geheimnis enthält ungültige Zeichen
Das Geheimnis sollte nur Buchstaben A-Z und Ziffern 2-7 enthalten
Wenn Sie keine Authenticator-App verwenden, entfernen Sie ROBINHOOD_TOTP_SECRET vollständig
Ratenbegrenzung:
robin_stocks hat keine integrierte Ratenbegrenzung
Wenn Sie Ratenbegrenzungen erreichen, warten Sie einige Minuten, bevor Sie es erneut versuchen
MIT
Dieses Tool dient nur zu Bildungs- und Forschungszwecken. Es verwendet inoffizielle APIs, die jederzeit ausfallen können. Die Autoren sind nicht verantwortlich für Kontobeschränkungen, Datenungenauigkeiten oder finanzielle Verluste.
Dieses Projekt ist nicht mit Robinhood Markets, Inc. verbunden, wird von dieser nicht unterstützt und steht in keiner Verbindung zu ihr.
Richten Sie einen Cron-Job ein, um ein tägliches Portfolio-Briefing zu erhalten:
# ~/.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 coffeeFühren Sie es täglich aus:
# 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.Mit 🧡 erstellt von Jack Arturo bei Very Good Plugins.
Unterstützt durch robin_stocks und FastMCP.
AutoMem - KI-Speicherinfrastruktur
Get all dividend payments received.
Returns list of dividend payments with amount, payable date, record date, and instrument details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only lists output fields without disclosing behavioral traits like authentication needs, rate limits, or side effects. Minimal transparency beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the verb and resource, second lists output fields. No redundant words, front-loaded, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema present, the description is largely sufficient. However, it lacks mention of pagination or any constraints, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so the baseline is 4. Schema coverage is 100% (vacuously), and the description adds no param info but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specific resource 'dividend payments received', distinguishing it from sibling tools like robinhood_get_earnings and robinhood_get_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites. The description only states what it does without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get earnings data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the basic purpose. It does not mention whether results are filtered by date, whether it returns future or past earnings, or any side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but could incorporate more useful information within its brevity without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description does not need to detail return values. However, it lacks context about the nature of earnings data (e.g., quarterly vs annual) and any filtering capabilities, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'symbol', with a clear description 'Stock ticker symbol'. The description adds no further meaning beyond the schema, achieving baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'earnings data' for a stock, distinguishing from siblings like get_quote or get_news. However, it does not specify what aspects of earnings (e.g., revenue, EPS, date) are included, which could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_fundamentals which might also include earnings. No exclusions or context provided, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fundamental data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'get fundamental data', not disclosing read-only nature, authentication needs, or any side effects. Vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words, but lacks structure or front-loading of critical info. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema present, the description is minimally adequate but omits behavior details. Could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'symbol' is described in the schema as 'Stock ticker symbol'. The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'fundamental data for a stock', distinguishing it from siblings like get_quote or get_ratings. However, it could be more specific about what fundamental data includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of siblings like robinhood_get_earnings or robinhood_get_dividends, which also provide fundamental data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol | |
| interval | No | Time interval (5minute, 10minute, hour, day, week) | day |
| span | No | Time span (day, week, month, 3month, year, 5year) | month |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It only states the tool retrieves historical data, but does not disclose key traits such as output format (OHLCV? adjusted?), rate limits, or data frequency nuances. This is insufficient for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) with no fluff. However, it could benefit from slightly more detail without sacrificing brevity, such as mentioning supported intervals or output type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. However, it lacks context about behavior like data granularity or historical range limitations, making it minimally adequate for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the schema already defines parameters (symbol, interval, span). The description adds no additional meaning beyond 'historical price data', yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'historical price data for a stock,' effectively distinguishing it from siblings like robinhood_get_quote (current price) and robinhood_get_fundamentals. However, it lacks explicit mention of time-range parameters that further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_quote for current price, get_dividends for dividend history). The description does not state prerequisites or typical use cases, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent news articles for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action, omitting details like rate limits, pagination, or the meaning of 'recent'. The read-only nature is implied but not confirmed, and potential limitations are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. Every word serves a purpose, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema exists), the description is adequate but leaves gaps: no mention of output format, number of articles, or time range. The existence of an output schema partially compensates, but behavioral context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter 'symbol' with description 'Stock ticker symbol'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent news articles for a stock' clearly states the verb (get), resource (news articles), and scope (recent, for a stock). It effectively distinguishes from sibling tools that deal with dividends, earnings, fundamentals, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like robinhood_get_ratings or robinhood_get_fundamentals. The purpose is self-evident, but the description does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all current options positions (read-only).
Returns list of options positions with chain symbol, type, strike price, expiration, and quantity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that the operation is 'read-only', which adds transparency. However, it does not disclose other behavioral traits such as pagination, rate limits, or authentication requirements beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loaded with the core action. Every sentence adds value without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the essential information. It could optionally mention that it returns positions for the authenticated user, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no parameter detail, but baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all current options positions (read-only)' and lists the returned fields. It effectively distinguishes from sibling tools like robinhood_get_positions by specifying 'options positions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. The name implies it is for options positions, but no alternatives are mentioned or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current portfolio value and performance metrics.
Returns portfolio profile with equity, extended hours equity, withdrawable amount, and other account details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation by stating it returns data, but does not explicitly disclose safety, authentication requirements, or rate limits. The lack of annotations places the burden on the description, which does not fully address these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only two sentences with no fluff. The first sentence states the purpose, and the second elaborates on return fields. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, output schema exists), the description is mostly complete. It lists key return fields. A minor improvement could mention that the data reflects current market conditions, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is trivially 100%. The description adds value by explaining what the tool returns (equity, extended hours equity, etc.) without repeating schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets portfolio value and performance metrics, listing specific fields like equity and withdrawable amount. It distinguishes itself from sibling tools like robinhood_get_dividends or robinhood_get_positions by focusing on the overall portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but given its simple nature (no parameters), usage is straightforward. Some mention of context (e.g., 'Use this to check your overall account summary') would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one current stock position with a faster single-symbol lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol (e.g., "HIMS", "AAPL") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description bears full burden. It describes a read operation but omits details like data freshness ('current'), authentication requirements, or rate limits. Minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and differentiator. No unnecessary words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 1-parameter tool with output schema, description is minimally adequate but lacks context on what 'current' means (e.g., real-time vs delayed) and any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description for 'symbol'. Description adds no additional meaning beyond schema, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves one current stock position, and 'faster single-symbol lookup' distinguishes it from the plural sibling tool 'robinhood_get_positions' which likely handles multiple symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for single-symbol lookups and suggests speed advantage, but does not explicitly exclude use cases or mention when to prefer the sibling tool for multiple symbols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all current stock positions with details.
Returns a dict mapping stock symbols to position details including price, quantity, average buy price, equity, and percent change.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It describes output structure but does not disclose behavioral traits like authentication requirements, data freshness, or that it is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second describes return format, third lists included details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, description adequately explains what the tool does and what it returns. Could mention that it pertains to the authenticated user, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, and description confirms it retrieves all positions. No additional meaning needed beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets all current stock positions with details, using specific verb 'get' and resource 'all current stock positions'. Distinguishes from sibling robinhood_get_position which gets a single position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies 'all current stock positions', providing context for when to use it. No explicit exclusions or alternatives, but sibling names imply it's the broadest retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time quote for a stock symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol (e.g., "AAPL", "TSLA") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does not mention any behavioral traits such as data freshness (e.g., 'real-time' is claimed but not qualified), limitations, or required permissions. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. However, it could be expanded slightly to include context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is minimally adequate. However, given the number of sibling tools, the agent could benefit from knowing that this is the primary quote endpoint or what specific fields the output contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'symbol' parameter is described as 'Stock ticker symbol'). The description adds no additional meaning beyond the schema, which is adequate for a single, well-known parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a real-time quote for a given stock symbol, using a specific verb ('get') and resource ('real-time quote'). It is distinct from sibling tools like robinhood_get_dividends or robinhood_get_historicals, which cover different financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. Given the set of similar data retrieval tools, explicit conditions or alternatives (e.g., 'for price data use this, for financial statements use fundamentals') are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analyst ratings summary for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description offers no behavioral details beyond the implied read operation. Does not mention authentication requirements, error handling for invalid symbols, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Efficient for a tool with one parameter, though it could be slightly more informative without much cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a simple input, the description is adequate but minimal. Does not leverage the presence of siblings to clarify positioning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'symbol', which already has a clear description. The tool description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Get'), the resource ('analyst ratings summary'), and the target ('a stock'). Distinguishes from sibling tools like robinhood_get_news or robinhood_get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool versus alternatives. Does not explain scenarios where ratings would be appropriate or when to use other tools like get_quote or get_fundamentals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stocks in a watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Watchlist name (default: "Default") | Default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It states only 'Get stocks in a watchlist,' which is a read operation, but does not confirm idempotency, authentication needs, or any side effects. The minimal description fails to provide safety guarantees beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, which is efficient and front-loaded. However, it could include a brief note on what the output contains or the parameter's impact without becoming verbose, making it slightly under-informative for a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description is minimally adequate. It does not mention the output format (though it can be inferred from the output schema) and lacks integration with sibling tools, leaving room for improvement in guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter, including a default value. The description does not add any meaning beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'stocks in a watchlist,' which distinguishes it from sibling tools like robinhood_get_portfolio or robinhood_get_positions. However, it lacks specificity about what details of the stocks are returned (e.g., symbols only or full data), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like robinhood_get_positions or robinhood_get_portfolio. The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stock symbols by company name or ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (company name or partial ticker) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose behaviors such as case sensitivity, exact vs. partial matching, or output format beyond the schema. Minimal detail limits an agent's ability to anticipate results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is easy to parse but could be more informative while remaining concise. A bit underspecified but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so complexity is low. The description adequately states the core function but omits behavioral traits like rate limits or read-only status. For a simple search tool, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'query' with a description matching the tool description. Since coverage is 100%, the baseline is 3. The description adds no additional meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for stock symbols by company name or ticker' clearly states the verb 'Search', the resource 'stock symbols', and the method (by name or ticker). It is distinct from sibling tools which focus on dividends, earnings, quotes, etc., avoiding confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding symbols but provides no explicit guidance on when to use this tool versus alternatives (e.g., to get quotes or fundamentals after searching). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2robinhood_get_dividendsrobinhood_get_earningsrobinhood_get_fundamentalsrobinhood_get_historicalsrobinhood_get_newsrobinhood_get_options_positionsrobinhood_get_portfoliorobinhood_get_positionrobinhood_get_positionsrobinhood_get_quoterobinhood_get_ratingsrobinhood_get_watchlistrobinhood_search_symbolsScored across 13 tools
Each tool targets a distinct data type (dividends, earnings, fundamentals, etc.) with clear boundaries. The only potential overlap is between get_position and get_positions, but they are differentiated by single vs. all symbols.
All tools follow a uniform 'robinhood_verb_noun' pattern, using snake_case and descriptive verbs (get, search). No mixing of styles or vague names.
13 tools is well-suited for a data-heavy financial service, covering a broad range of endpoints without being overwhelming. The count feels neither sparse nor excessive.
The tool set comprehensively covers read-only data retrieval (quotes, positions, dividends, earnings, news, etc.), but lacks write operations (e.g., placing orders) which might be expected from a brokerage service. Minor gap for transactional use cases.
Read-only MCP server for Robinhood Chain token discovery, research, and due diligence via GMGN.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Read-only MCP server exposing a user ORANO library to their own AI agent.
MCP server exposing the Backtest360 engine API as tools for AI agents.
