Рабочая копия drasticstatic — используется системой Fortuna trading system. Это независимый репозиторий, созданный на основе локального клона verygoodplugins/robinhood-mcp. Апстрим отслеживается как удаленный репозиторий для добровольного сравнения — изменения проверяются перед применением.
# Check for upstream updates (review before applying) git fetch upstream && git log upstream/main --oneline
MCP-сервер с правами только на чтение для анализа портфеля Robinhood. Использует robin_stocks, чтобы предоставить ИИ-ассистентам доступ к данным вашего портфеля для анализа.
⚠️ Только для исследовательских целей — этот сервер предоставляет доступ только на чтение. Функционал для торговли отсутствует.
⚠️ Неофициальный API — использует неофициальный API robin_stocks. Может перестать работать без предупреждения. Используйте на свой страх и риск.
После подключения вы можете вести естественный диалог с Claude о своем портфеле:
"Проверь состояние моего портфеля. Какова его общая стоимость, концентрация по секторам и есть ли позиции, которые значительно выросли или упали?"
Claude получит данные о ваших позициях, рассчитает отраслевую экспозицию, определит лучшие и худшие активы и укажет на риски концентрации.
"Я думаю об увеличении позиции в NVDA. Покажи мне фундаментальные показатели, последние новости, рейтинги аналитиков и динамику за последний год."
Получите комплексное исследование, объединяющее историю цен, коэффициенты P/E, даты отчетности и настроения аналитиков в одном ответе.
"Сравни круизные компании в моем портфеле — покажи CCL, RCL и NCLH рядом с их коэффициентами P/E, рыночной капитализацией и доходностью с начала года."
Быстро оценивайте похожие активы для определения относительной стоимости.
"Какие дивиденды я получил в этом году? Какие из моих активов выплачивают дивиденды и какова их доходность?"
Отслеживайте пассивный доход и находите дивидендные возможности в своем портфеле.
"Какова моя экспозиция на энергетический сектор? Насколько высока концентрация в моих 5 крупнейших позициях?"
Анализируйте отраслевую концентрацию и выявляйте позиции, которые могут быть перевешены.
"У каких из моих активов ожидается публикация отчетности в ближайшие две недели?"
Будьте готовы к волатильности на фоне отчетности с помощью персонализированного календаря.
"Разбери доходность моего портфеля. Что именно приносит мне прибыль, а что — убытки?"
Поймите, какие позиции вносят наибольший вклад в вашу доходность.
"Получи котировки и фундаментальные показатели для всего, что есть в моем списке наблюдения. Что выглядит интересно прямо сейчас?"
Массово исследуйте акции, за которыми вы следите.
Related MCP server: Public.com MCP Server
pip install robinhood-mcpИли запустите напрямую с помощью uvx:
uvx robinhood-mcpexport ROBINHOOD_USERNAME="your_email"
export ROBINHOOD_PASSWORD="your_password"
export ROBINHOOD_TOTP_SECRET="your_2fa_secret" # Only if you use authenticator appПримечание: Если вы используете Face ID, Touch ID или вход по паролю в Robinhood (без приложения-аутентификатора), вам не нужен ROBINHOOD_TOTP_SECRET.
Добавьте в ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"robinhood": {
"command": "uvx",
"args": ["robinhood-mcp"],
"env": {
"ROBINHOOD_USERNAME": "your_email",
"ROBINHOOD_PASSWORD": "your_password"
}
}
}
}claude mcp add robinhood -- uvx robinhood-mcpИнструмент | Описание |
| Стоимость портфеля, капитал, покупательная способность, изменение за день |
| Все активы с ценой приобретения, текущей стоимостью, P&L |
| Один актив по тикеру с количеством, стоимостью и P&L |
| Акции в ваших списках наблюдения |
| Цена в реальном времени, bid/ask, объем |
| P/E, рыночная капитализация, дивидендная доходность, диапазон 52 недель |
| История цен OHLCV (день/неделя/месяц/год) |
| Последние новости по символу |
| Даты отчетности, прогнозы EPS, фактические данные |
| Рейтинги аналитиков (buy/hold/sell) |
| История выплаты дивидендов |
| Текущие позиции по опционам |
| Поиск акций по названию или тикеру |
Простые запросы:
"Сколько сейчас стоит мой портфель?"
"Покажи мои 5 крупнейших позиций по стоимости"
"Владею ли я уже HIMS и какова моя текущая позиция?"
"Получи котировку для AAPL"
Для вопросов по одной акции лучше использовать robinhood_get_position вместо robinhood_get_positions. Инструмент для одного символа позволяет избежать пересчета всех активов и работает намного быстрее для вопросов типа "Стоит ли мне докупить HIMS?"
Запросы на анализ:
"Сравни фундаментальные показатели GOOGL и META"
"Какие из моих акций торгуются ниже их среднего значения за 52 недели?"
"Покажи график цены TSLA за последний год"
"Какая акция у меня самая прибыльная? А какая самая убыточная?"
Исследовательские рабочие процессы:
"Я хочу понять индустрию круизных линий. Получи данные по CCL, RCL и NCLH — сравни их фундаментальные показатели и недавнюю динамику."
"Найди в моем портфеле акции с P/E ниже 15 и положительным ростом прибыли"
"Я в большом минусе по нескольким позициям. Покажи фундаментальные показатели и новости по моим худшим активам, чтобы помочь мне решить, стоит ли держать их или зафиксировать убытки."
Только чтение: Нельзя совершать сделки, изменять списки наблюдения или настройки аккаунта
Неофициальный API: Robinhood может изменить свой API в любой момент, что приведет к поломке функционала
Нет потоковых данных в реальном времени: Котировки актуальны на момент запроса, это не живой поток
Истечение сессии: Возможно, вам придется периодически проходить повторную аутентификацию
Лимиты запросов: Интенсивное использование может привести к срабатыванию ограничений Robinhood
Учетные данные используются только локально для аутентификации в Robinhood
Токены сессии кэшируются в ~/.tokens/robinhood.pickle библиотекой robin_stocks
Никогда не коммитьте файл .env и не раскрывайте учетные данные
Этот инструмент не может совершать сделки — он спроектирован только для чтения
git clone https://github.com/verygoodplugins/robinhood-mcp.git
cd robinhood-mcp
pip install -e ".[dev]"
# Lint
ruff check . && ruff format --check .
# Test
pytest
# Run locally
robinhood-mcpОшибки "Not logged in":
Проверьте правильность имени пользователя и пароля
Если у вас включена 2FA через приложение-аутентификатор, вам нужен ROBINHOOD_TOTP_SECRET
Попробуйте войти через приложение Robinhood, чтобы убедиться, что аккаунт не заблокирован
Ошибка "Non-base32 digit found":
Ваш TOTP-секрет содержит недопустимые символы
Секрет должен содержать только буквы A-Z и цифры 2-7
Если вы не используете приложение-аутентификатор, полностью удалите ROBINHOOD_TOTP_SECRET
Ограничение частоты запросов (Rate limiting):
В robin_stocks нет встроенного ограничения частоты запросов
Если вы столкнулись с лимитами, подождите несколько минут перед повторной попыткой
MIT
Этот инструмент предназначен только для образовательных и исследовательских целей. Он использует неофициальные API, которые могут перестать работать в любой момент. Авторы не несут ответственности за любые ограничения аккаунта, неточности данных или финансовые потери.
Этот проект не связан, не одобрен и не имеет отношения к Robinhood Markets, Inc.
Настройте cron-задачу для получения ежедневного брифинга по портфелю:
# ~/.claude/commands/portfolio-review.md
---
description: "Daily portfolio health check"
---
Using the robinhood MCP tools:
1. Get my current portfolio value and day change
2. Identify my top 3 gainers and top 3 losers today
3. Flag any positions that are down more than 20% from cost basis
4. Check if any holdings have earnings in the next 7 days
5. Give me a 2-3 sentence summary I can read with my morning coffeeЗапускайте ежедневно:
# Add to crontab -e
0 7 * * 1-5 cd ~/Projects && claude -p "/portfolio-review" --dangerously-skip-permissions >> ~/portfolio-reports/$(date +\%Y-\%m-\%d).md# ~/.claude/commands/weekly-research.md
---
description: "Weekly deep dive on portfolio"
---
For each of my top 10 holdings by value:
1. Pull current fundamentals and compare to sector averages
2. Get recent news and analyst rating changes
3. Flag any significant changes from last week
4. Identify 2-3 stocks from my watchlist that might be worth adding
Format as a markdown report I can review on the weekend.Создано с 🧡 Jack Arturo в Very Good Plugins.
Работает на базе robin_stocks и FastMCP.
AutoMem — инфраструктура памяти для ИИ
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.
