How do I use StonkBroker Agent?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@StonkBroker Agent Inspect StonkBroker #1 and show its stock-token portfolio." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

StonkBroker Agent

by slkzgm

Overview Schema Source Related Servers Discussions Admin

TypeScript

StonkBroker Agent

License: MIT Node.js 20+

An MCP server that gives an AI agent controlled access to a StonkBroker NFT's ERC-6551 token-bound wallet (TBA). The agent can inspect the wallet, quote a stock-token swap, execute it on Robinhood Chain through Uniswap, and automatically publish the confirmed trade to X.

This is independent, experimental software and is not affiliated with or endorsed by Robinhood, StonkBrokers, Uniswap, or X. Stock tokens and automated trading involve financial risk; start in read-only mode.

The implementation targets the canonical mainnet contracts and APIs that are live today:

Robinhood Chain: chain ID 4663
StonkBrokers NFT: 0x539CdD042c2f3d93EbC5BE7DfFf0c79F3B4fAbF0
Verified TBA implementation: 0xE946075125843aAdb5e40e59f513d929AF507C4B
Canonical stock-token registry: https://api.robinhood.com/rhj/assets
Uniswap Trading API: classic V2/V3/V4 routes on chain 4663
X API: POST /2/tweets with OAuth user context

How it works

AI agent
   │ MCP tools
   ▼
quote_stock_trade ──► Robinhood canonical asset registry
   │                  Uniswap Trading API (quote only)
   ▼
execute_stock_trade (explicit confirmation + live-trading gate)
   │
   ├─ verify NFT owner ↔ TBA binding
   ├─ enforce exact token approval and MAX_TRADE_BPS
   ├─ owner EOA calls TBA.executeCall(token.approve)
   ├─ owner EOA calls TBA.executeCall(Uniswap swap)
   ├─ wait for a successful Robinhood Chain receipt
   ├─ measure actual input/output balance deltas
   └─ persist trade in outbox ──► X API post + automatic retries

The agent never trades from the owner's EOA. The TBA is the swapper and recipient; the EOA only authorizes executeCall because it currently owns the NFT and pays network gas.

Related MCP server: Scorched

Quick start

Any MCP client that can launch a stdio server can run the latest public source directly from GitHub—no clone or global installation required:

{
  "mcpServers": {
    "stonkbroker": {
      "command": "npx",
      "args": ["--yes", "github:slkzgm/stonkbroker-agent"],
      "env": {
        "BROKER_TOKEN_ID": "1"
      }
    }
  }
}

Restart the MCP client, then ask: Inspect StonkBroker #1 and show its stock-token portfolio.

The default configuration is read-only: it uses the public Robinhood Chain RPC, does not need a wallet key, and cannot trade. See Enable live trading only when you are ready to perform the bounty proof with a low-value wallet.

MCP tools

Tool	Effect
`system_health`	Read-only connectivity and configuration check; never reveals secrets.
`broker_status`	Verifies the ERC-6551 binding and lists canonical Robinhood stock-token balances.
`list_stock_tokens`	Searches Robinhood's live canonical asset registry.
`quote_stock_trade`	Returns a 30-second exact-input Uniswap quote. No signing or transaction.
`execute_stock_trade`	Requires `confirmation: "EXECUTE"`, submits the TBA calls, and queues/posts the trade to X.
`retry_x_posts`	Retries queued X posts for confirmed swaps.

Install from source

Requirements: Node.js 20+ and pnpm.

git clone https://github.com/slkzgm/stonkbroker-agent.git
cd stonkbroker-agent
corepack enable
pnpm install
cp .env.example .env
pnpm run build
pnpm run verify:chain

Read-only inspection works with the default public RPC and no secrets:

pnpm run cli -- status --token-id 1
pnpm run cli -- tokens --query AAPL

The packaged CLI can also be used without cloning:

npx --yes --package=github:slkzgm/stonkbroker-agent stonkbroker-cli status --token-id 1

# Equivalent pnpm command
pnpm dlx --package=github:slkzgm/stonkbroker-agent stonkbroker-cli status --token-id 1

Enable live trading

To request quotes, set UNISWAP_API_KEY. To execute a trade, also set the following values in a local .env file or your MCP client's private environment:

BROKER_TOKEN_ID=<your broker id>
OWNER_PRIVATE_KEY=0x...
ALLOW_LIVE_TRADING=true
X_USER_ACCESS_TOKEN=<OAuth user token with tweet.read tweet.write users.read>
REQUIRE_X_POST=true
X_DRY_RUN=false

The signer must be the current onchain owner of the selected StonkBroker. It also needs a small amount of ETH on Robinhood Chain for gas. Never put a key in source code or an MCP prompt.

Capture a bounty proof

The packaged proof runner connects to the real MCP server as a client and saves a reviewable, mode-0600 JSON artifact. Its inspection mode is read-only:

pnpm run build
pnpm run proof -- --inspect-only --token-id 1

With a controlled StonkBroker and the live variables above configured, run a tiny proof trade:

pnpm run proof -- --token-id 123 --in AAPL --out NVDA --amount 0.001 --slippage 0.5

The runner records the MCP tool list, system health, verified TBA, quote, confirmed transaction, and X result in .stonkagent/bounty-proof.json. It prints the quote and requires the operator to type the literal EXECUTE before anything is signed. Credentials are inherited by the child MCP process but are never printed or written to the evidence file.

It can also run directly from the public release:

npx --yes --package=github:slkzgm/stonkbroker-agent#v0.2.0 \
  stonkbroker-proof --inspect-only --token-id 1

Connect an agent

For a local clone, build first and configure any MCP client to spawn the server over stdio:

{
  "mcpServers": {
    "stonkbroker": {
      "command": "node",
      "args": ["/absolute/path/to/stonkbroker/dist/src/server.js"],
      "env": {
        "BROKER_TOKEN_ID": "123",
        "UNISWAP_API_KEY": "...",
        "OWNER_PRIVATE_KEY": "0x...",
        "ALLOW_LIVE_TRADING": "true",
        "X_USER_ACCESS_TOKEN": "..."
      }
    }
  }
}

For Docker, build the image and keep stdin open for the MCP transport:

docker build -t stonkbroker-agent .
mkdir -p .stonkagent
docker run --rm -i --env-file .env \
  -v "$PWD/.stonkagent:/data" stonkbroker-agent

Suggested demo conversation:

Inspect StonkBroker #123 and show its stock-token portfolio.
Quote swapping 0.001 AAPL to NVDA with 0.5% slippage.
Review the route, amounts, expiry, and wallet returned by the agent.
Execute quote <id> with confirmation EXECUTE.
Open the returned Blockscout transaction and X post.

Safety properties

Live trading is off by default.
A quote cannot spend more than MAX_TRADE_BPS of the current input-token balance (5% by default).
Only canonical contracts returned by Robinhood's live registry can be selected.
Quotes are forced to immediate Uniswap AMM routes; intent orders are not used.
Permit2 is disabled. Any mismatched existing allowance is first cleared, then set to the exact input amount for Uniswap's deterministic Swap Proxy.
The NFT owner, predicted TBA, deployed TBA, implementation, TBA owner, token contract, and token ID are checked before trading.
Quote input, output, amount, and recipient must exactly match the request.
Swap calldata must identify the TBA as from, target chain 4663, call only the official Swap Proxy and Universal Router 2.1.1, bind the exact input token and amount, send zero native value, use a short deadline, and survive an eth_call simulation through executeCall.
V2, V3, nested, and V4 router plans are decoded: Permit2-funded, allow-revert, exact-output, partial-output, and unrelated commands are rejected, and the complete output must be addressed explicitly to the TBA rather than the Swap Proxy.
A quote expires after 30 seconds and is removed after one execution attempt.
Actual post amounts come from confirmed onchain balance deltas, not the pre-trade quote.
Confirmed trades enter a mode-0600 durable outbox before the first X request. Failed posts are retried every minute and through retry_x_posts.
When REQUIRE_X_POST=true, live trading refuses to start without a real X user token or while X dry-run mode is enabled.

Verification

pnpm run check
pnpm run test
pnpm run build
pnpm run verify:chain

verify:chain performs live read-only checks against chain 4663, including the NFT/TBA linkage, canonical stock-token balances, Universal Router 2.1.1, and Swap Proxy deployments. The test suite covers canonical-asset filtering, quote binding, decoded V2/V3/V4 calldata safety, complete trade orchestration, X post formatting, and outbox persistence. stonkbroker-proof --inspect-only additionally exercises the packaged MCP client/server boundary without enabling transactions.

Robinhood Trading MCP and onchain execution

Robinhood's Agentic Trading documentation describes the Robinhood Trading MCP as connecting an AI agent to a dedicated Robinhood Agentic brokerage account, and explicitly says the agent can only place trades in that Agentic account. Separately, Robinhood's Chain documentation says Robinhood Chain operates independently of Robinhood brokerage and crypto accounts.

The bounty targets a StonkBroker's ERC-6551 wallet on Robinhood Chain, so this project provides a separate MCP execution path for that onchain account. The current NFT owner authorizes the TBA call, and this implementation chooses Uniswap as its swap venue. Uniswap is an implementation choice, not a claim that it is the only possible onchain venue.

An agent may connect to both MCP servers: Robinhood Trading MCP for the brokerage capabilities Robinhood documents, and this server for the StonkBroker TBA. Based on the currently published interfaces, Robinhood Trading MCP alone is not an execution interface for the TBA. See the architecture evidence and claim boundaries.

External prerequisites for a public bounty demo

The implementation and test harness contain no embedded credentials. The bounty must not be claimed as verified until a public live proof provides:

A StonkBroker controlled by the demo signer.
Input stock-token balance in its TBA.
Enough ETH in the owner EOA for Robinhood Chain gas.
A Uniswap Developer API key.
An X developer app and OAuth user access token with tweet.read, tweet.write, and users.read.

Stock tokens and automated trading involve financial risk. Use a tiny amount for the proof transaction.

Contributing and security

Contributions are welcome. Read CONTRIBUTING.md before opening a pull request. Report vulnerabilities privately as described in SECURITY.md; never publish keys, tokens, or an unpatched exploit.

Licensed under the MIT License.

Available Tools

6 tools

broker_statusA

Read-onlyIdempotent

Inspect a StonkBroker NFT, verify its ERC-6551 binding, and list canonical Robinhood stock-token balances in its token-bound wallet.

ParametersJSON Schema

Name	Required	Description	Default
`tokenId`	No	StonkBroker token ID

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by detailing the specific inspection actions (verifying ERC-6551 binding, listing balances). It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the main verb 'Inspect' and covers all key actions without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's three main actions (inspect, verify, list) and references specific constraints (ERC-6551, token-bound wallet). It lacks details about output format or what 'canonical' means, but given the low complexity and single parameter, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for tokenId ('StonkBroker token ID'). The description does not add further meaning beyond what the schema already provides, meeting baseline expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's verb ('Inspect'), the resource ('StonkBroker NFT'), and the specific actions (verify ERC-6551 binding, list balances). It distinguishes itself from sibling tools that deal with system health, stock tokens, quotes, trades, or retries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for inspecting a specific NFT token, but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not or prerequisite conditions. Context from sibling tools helps but is not part of the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_stock_tradeA

Destructive

Execute a previously quoted trade from the StonkBroker ERC-6551 wallet, wait for confirmation, then automatically post the actual balance deltas and transaction link to X.

ParametersJSON Schema

Name	Required	Description	Default
`quoteId`	Yes
`confirmation`	Yes

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (destructiveHint=true), description reveals it auto-posts balance deltas and transaction link to X. However, does not disclose handling of failures or X posting errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence front-loads the action and key steps. Efficient, but could benefit from structured list for clarity. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers side effect (X post) and destructive nature, but lacks return value description, failure scenarios, or integration with sibling tools for status checks. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%. Description does not explain 'quoteId' or 'confirmation' parameters. 'confirmation' with const 'EXECUTE' is not mentioned, leaving agents to infer meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool executes a previously quoted trade from the StonkBroker ERC-6551 wallet, waits for confirmation, and posts results to X. Differentiates from sibling 'quote_stock_trade' which provides the quote.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies a prior quote is needed but does not explicitly state when not to use this tool or mention alternatives for retrying or checking status. No exclusionary guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_stock_tokensA

Read-onlyIdempotent

List canonical stock tokens from Robinhood's live asset registry. Use a symbol or contract substring to filter results.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, providing a strong safety profile. The description adds context about the data being 'canonical' and 'live', which is mildly helpful but does not disclose further behavioral traits like pagination, rate limits, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The first sentence states the primary purpose, and the second provides a usage hint. No extraneous text; efficiently front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with filter, the description is adequate but lacks details on return format, pagination behavior, and the exact semantics of 'canonical'. Without an output schema, the agent may need more information to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description partially explains the 'query' parameter (filtering by symbol/contract substring) but provides no information about the 'limit' parameter. With 0% schema description coverage, the description fails to compensate adequately for both parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('list'), the resource ('canonical stock tokens'), and the source ('Robinhood's live asset registry'). It also specifies the filtering mechanism using symbol or contract substring, which distinguishes it from sibling tools like quote_stock_trade or execute_stock_trade.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing to look up stock tokens by symbol/contract substring, but does not explicitly state when to use this tool versus alternatives. Sibling tools provide context, but the description lacks direct guidelines on when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

quote_stock_tradeA

Read-only

Request a time-limited Uniswap quote for an exact-input trade between canonical Robinhood stock tokens held by a StonkBroker TBA. This never signs or submits a transaction.

ParametersJSON Schema

Name	Required	Description
`amount`	Yes	Human-readable input amount
`tokenId`	No
`tokenIn`	Yes	Canonical token symbol or contract address
`tokenOut`	Yes	Canonical token symbol or contract address
`slippagePercent`	No

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true; description adds that it is time-limited and uses Uniswap, and explicitly states it never signs or submits. No contradiction. Adds useful context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and key behavioral trait. No redundant information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not explain the return structure (e.g., quote details, expiry). It mentions 'time-limited' but remains vague. For a 5-parameter tool with varying schema coverage, missing return info and parameter overview reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 60%, with some parameters having no description (tokenId). The tool description does not elaborate on parameters, leaving the schema to do the work. Could be improved by explaining tokenId or slippage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'request a quote', the resource 'Uniswap quote for stock tokens held by a StonkBroker TBA', and specifies it is for exact-input trades. This distinguishes it from the sibling 'execute_stock_trade' which signs/submits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly notes this should be used for getting a quote before execution, and that it never signs or submits. Implies when-not-to-use (for actual execution) and contrasts with execute_stock_trade. Could be more explicit about prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

retry_x_postsA

Idempotent

Retry every queued X post for confirmed trades. Confirmed trades are durably queued before the first posting attempt.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds value beyond annotations by explaining durability of queuing, which implies idempotency. Aligns with idempotentHint=true and destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. Information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple retry tool with no output schema. Minor gap: does not specify behavior when no queued posts exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; description does not need to add param info. Baseline score for 0 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it retries queued X posts for confirmed trades. The verb 'retry' and resource 'queued X posts' are specific. However, it could explicitly mention it's for failed posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 execute_stock_trade. No conditions or exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

system_healthA

Read-onlyIdempotent

Check Robinhood Chain connectivity and whether quote, signing, live trading, and X posting credentials are configured. Never returns secrets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds the critical behavioral note 'Never returns secrets' beyond what annotations provide (readOnlyHint, idempotentHint, destructiveHint). This is valuable for an agent evaluating safety. However, it does not describe other behaviors like response format or error handling, so it is not a full 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no superfluous words. The first sentence immediately states the purpose, and the second sentence adds a critical behavioral constraint. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool has no input parameters and annotations cover safety, there is no output schema and the description does not describe what the response looks like (e.g., boolean, detailed status). For a health-check tool, agents would benefit from knowing the return format to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters (schema coverage 100% by default), so baseline is 4. The description does not need to add parameter details since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it checks Robinhood Chain connectivity and credential configuration for quote, signing, live trading, and X posting. This is a specific verb+resource combination, and it distinguishes itself from siblings like broker_status or execute_stock_trade by focusing on system health rather than trading or status of a specific broker.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like broker_status or retry_x_posts. The description only states what it checks, not when it is appropriate to invoke. An agent would have to infer use cases without explicit when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.2.0Jul 28, 2026
- First observedbroker_status
- First observedexecute_stock_trade
- First observedlist_stock_tokens
- First observedquote_stock_trade
- First observedretry_x_posts
- First observedsystem_health

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-07-28 07:00 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: system health, NFT status, token listing, quote retrieval, trade execution, and X post retry. There is no functional overlap or ambiguity.

Naming Consistency5/5

All tool names use consistent snake_case and follow a predictable verb_noun pattern (e.g., list_stock_tokens, execute_stock_trade), with the exception of system_health and broker_status which are noun_noun but still fit the same style. No mixing of conventions.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose: it covers health check, wallet inspection, token listing, quoting, execution, and X posting retry. This is neither too few nor too many for a trading agent.

Completeness4/5

The tool set covers the core trading workflow end-to-end (check, inspect, list, quote, execute, retry). A minor gap is the lack of a tool to view transaction history or cancel pending trades, but the core functionality is fully covered.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Hive Capital A
io.github.srotzin
HiveCapital MCP Server — autonomous investment layer for AI agents
Finance Autonomous Agents Blockchain
2
x402-services A
ai.firmbrain
The only x402 MCP server for Robinhood Chain (chainId 4663) - 147 onchain, trading & AI tools.
Blockchain Cryptocurrency Finance
1592
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2

Related MCP Servers

uniswap-trader-mcp
Blockchain Web3 & Decentralized Tech
kukapay
A
license
Not graded
quality
F
maintenance
An MCP server for AI agents to automate token swaps on Uniswap DEX across multiple blockchains.
Updated a year ago (2025-05-07 17:23 UTC)
5 npm
38
MIT
Scorched
Finance AI & Machine Learning Autonomous Agents
willcassell
A
license
Not graded
quality
B
maintenance
An MCP server that lets you talk to your AI trading assistant in plain English to research stocks, generate trade recommendations, manage a portfolio, and execute trades through natural language.
Updated 14 days ago (2026-08-31 12:22 UTC)
MIT
x402 MCP Server
Finance Cryptocurrency
fernsugi
A
license
Not graded
quality
D
maintenance
An MCP server that provides DeFi data tools (crypto prices, whale concentration, funding rates) for AI agents via the x402 protocol.
Updated 7 months ago (2026-02-21 17:50 UTC)
10 npm
1
MIT
cook4fun-mcp
htunaa
F
license
A
quality
B
maintenance
An MCP server that lets agents launch and trade coins on cook4.fun, a Uniswap-V3-native launchpad on the Robinhood chain.
Updated 2 months ago (2026-07-21 17:06 UTC)
6
1
-