Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Capital Press MCP What are the latest presses for TSLA?"
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.
MCP (Model Context Protocol) server for Capital Press, the news marketplace for tokenized stocks on Robinhood Chain (chain id 4663).
It lets any MCP client (Claude, Cursor, and others) browse presses, check the AI audit and the onchain votes, buy the full text of a press with USDG over x402, and vote on what it read.
Browsing is free and needs no account, no API key and no wallet. Buying and voting need a wallet key that you provide. The key stays on your machine: payments are signed locally and only the signature is sent.
Free, no wallet needed:
list_presses: live presses, newest first, with the free preview, price, audit score, votes and read count. Filter by ticker with stock.
get_press: everything free about one press, by pressId or slug. Includes the audit verdict and summary, and the stock price at publication and now. If the wallet already owns the press, the saved full text is included.
list_stocks: the tokenized stocks a press can be about. Filter with search.
get_quote: latest price data for one stock token.
agent_guide: the machine-readable guide to the API and the payment flow.
With a wallet:
wallet_status: address, ETH and USDG balances, approval state, the spend cap and the size of the local library.
approve_usdg: the one-time onchain approval that payments need. Costs a little ETH for gas.
buy_press: buys the full text of one press. It makes two x402 payments (10% platform fee, then 90% to the publisher), saves the text locally and returns it.
read_purchased: lists or reads the presses saved locally. Free and offline.
vote_press: casts an onchain vote, up or down, with an optional tag (accurate, well-sourced, insightful, misleading, outdated, biased). Costs a little ETH for gas.
Related MCP server: storyflo
Requires Node.js 20 or newer.
git clone https://github.com/capitalpressdev/mcp.git capitalpress-mcp
cd capitalpress-mcp
npm install
npm run buildBrowsing only:
claude mcp add capitalpress -- node /path/to/capitalpress-mcp/dist/index.jsWith a wallet:
claude mcp add capitalpress --env CAPITALPRESS_PRIVATE_KEY=0xyourkey -- node /path/to/capitalpress-mcp/dist/index.jsAdd this to the client's MCP config (claude_desktop_config.json, .cursor/mcp.json, and so on):
{
"mcpServers": {
"capitalpress": {
"command": "node",
"args": ["/path/to/capitalpress-mcp/dist/index.js"],
"env": {
"CAPITALPRESS_PRIVATE_KEY": "0xyourkey",
"CAPITALPRESS_MAX_PRICE_USDG": "2"
}
}
}
}Leave out env to run in browse-only mode.
Variable | Default | What it does |
| not set | Private key of the agent's wallet. Without it the server is browse-only. |
|
| The most the server will pay for one press. Presses cost between 0.05 and 10 USDG. |
|
| Where purchased presses are saved. |
|
| API base, for local development. |
The wallet lives on Robinhood Chain and needs two things:
USDG (0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168) to pay for presses.
A little ETH for gas. It is used for the one-time approval and for votes. Payments themselves cost no gas: the wallet only signs, and settlement is done for it.
Run wallet_status to see the address and what is missing, then approve_usdg once before the first purchase.
The server looks up the press and its listed price.
It posts to /api/pay/treasury and gets HTTP 402 with the payment terms. It signs them and repeats the request with the payment-signature header. This is the 10% fee.
It does the same on /api/pay/publisher for the remaining 90%. The response holds the full text.
The text is saved under CAPITALPRESS_DATA_DIR, because a wallet can't pay twice for the same press.
If the wallet already has access to a press (bought on the site, bought on another machine, or published by it), buy_press signs in with a free message signature, fetches the text and pays nothing. If a purchase is interrupted after the fee, run buy_press again: a settled fee is not charged twice.
Use a dedicated wallet that holds only what the agent may spend. Never use your main wallet.
Before signing a payment the server checks that:
the token is USDG on Robinhood Chain
the spender is the known x402 Permit2 contract
the amount is exactly the fee or the publisher share of the listed price
the publisher payment goes to the current onchain owner of the press
the price is within CAPITALPRESS_MAX_PRICE_USDG and within maxPriceUsdg if the call sets one
If any check fails, nothing is signed. The private key is never logged and never leaves the process.
Ask your client: "What's new on Capital Press about NVDA? If the audit score is above 80 and it costs 1 USDG or less, buy it and summarize it."
The agent calls list_presses with stock: "NVDA", reads the preview and audit with get_press, then calls buy_press with maxPriceUsdg: 1 and works from the returned text.
Nothing published on Capital Press is investment advice.
MIT
The machine-readable Capital Press guide: network, token, endpoints and the x402 payment flow. Useful when building a client without this server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds value by specifying exactly what the guide contains (network, token, endpoints, payment flow), which helps the agent anticipate the response structure without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose ('machine-readable guide') and a clear list of covered topics. No wasted words; every clause adds information.
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 guide tool with no params and no output schema, the description sufficiently covers what the guide includes. It might optionally mention the return format, but given the simplicity, the description is adequate for an agent to decide to call it and anticipate generic content.
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 tool has zero parameters, so the schema is empty. The description correctly omits param-specific details. Per baseline for 0-param tools, this scores high since there is nothing to clarify.
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 states a specific artifact: 'machine-readable Capital Press guide' and enumerates its contents (network, token, endpoints, x402 payment flow). It clearly distinguishes itself from sibling tools, which are actions (buy, vote, list, etc.), by being a reference guide.
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?
It explicitly says it is 'useful when building a client without this server', giving a clear target scenario. It doesn't mention alternatives, but the nature of a guide makes it obvious when to use it; no exclusions are needed because it's a read-only reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-time onchain approval that lets the Permit2 contract move USDG this wallet later signs for. Needed once before the first purchase. Costs a little ETH for gas. Each payment still needs its own signature.
| Name | Required | Description | Default |
|---|---|---|---|
| amountUsdg | No | Approve only this much USDG. Leave out for an unlimited approval, which never needs repeating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, but the description adds valuable behavioral context: it is a one-time onchain action, costs ETH for gas, and requires subsequent signatures for each payment. This goes beyond what annotations provide without contradicting them.
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?
Every sentence earns its place: what it is, when it is needed, what it costs, and what it does not do. The most important fact ('one-time onchain approval') is front-loaded, and there is no filler.
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 one-parameter transaction tool, the description covers the core prerequisites, cost, and follow-up expectations. It does not describe the success/return value, but with no output schema and a straightforward onchain action, the omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter's own description already explains the optional amount and the unlimited-approval alternative. The tool description adds no further parameter-level detail, so the 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 identifies the action ('approve'), the resource (USDG), and the mechanism (Permit2 contract), while distinguishing this from purchase actions like buy_press. 'One-time onchain approval' makes the purpose unmistakable.
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 explicitly states when this is needed ('before the first purchase') and clarifies that each payment still requires its own signature. It does not name alternatives or explicitly describe when not to use it, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy the full text of one press with USDG. Makes two x402 payments (10% platform fee, then 90% to the publisher), saves the text locally and returns it. Spends real funds. A press this wallet already owns is returned without paying again.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | The slug of the press. Use this or pressId. | |
| pressId | No | The onchain id of the press, as returned by list_presses. | |
| maxPriceUsdg | No | Refuse to buy if the press costs more than this. The server-wide cap still applies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical behavioral details: it 'Makes two x402 payments (10% platform fee, then 90% to the publisher)', 'saves the text locally', and warns that it 'Spends real funds.' It also accurately reflects the idempotentHint by stating that already-owned presses are returned without paying again. This is rich, practical behavior disclosure.
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 sentences, front-loaded with the core action, and every sentence earns its place: what is bought, how payment works, the financial warning, and idempotent behavior. There is no filler or repetition of schema content.
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 paid purchase tool with no output schema, the description is complete enough: it states the return behavior ('returns it'), the local save, the exact fee split, the real-funds risk, and the already-owned bypass. Combined with the fully described schema and annotations, nothing essential is missing for an agent to call this correctly.
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%, so the schema fully documents slug, pressId, and maxPriceUsdg. The description does not add parameter-level semantics, but per the high-coverage baseline, that is acceptable. It does not need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Buy the full text of one press with USDG.' It clearly separates this payment-required operation from read-only sibling tools like read_purchased or get_press, and the added payment-fee detail makes the tool's function unambiguous.
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 clear context: it is used when you want to purchase full-text access, and it even notes that already-owned presses are returned without another payment. However, it does not explicitly recommend read_purchased as the cheaper/free alternative for already-owned presses, so the when-not-to-use guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free details for one press: preview, audit verdict and summary, votes, price, and the stock price at publication and now. If this wallet already bought it, the saved full text is included.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | The slug of the press. Use this or pressId. | |
| pressId | No | The onchain id of the press, as returned by list_presses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavioral context: the operation is free, returns dynamic data ('stock price ... now'), and conditionally includes full text when the wallet already purchased the press. This goes beyond what annotations alone convey.
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 tightly written sentences: the first front-loads the resource and return-field list, and the second adds an important conditional behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the main response fields and the one conditional behavior, which is adequate for a simple read-only lookup. It does not describe error cases or exact response formatting, but those are minor gaps for this tool.
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%, so the schema already explains slug and pressId sufficiently. The description does not add meaningful parameter-level guidance beyond referring to a single press, which is not necessary given the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves details for one press and enumerates the exact fields returned: preview, audit verdict, summary, votes, price, and stock prices. It distinguishes itself from list_presses by scoping to a single press and from read_purchased by noting the full text is included only if already purchased.
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 this is the general detail-lookup tool ('Free details for one press'), but it does not explicitly state when to use it instead of siblings like list_presses or read_purchased. The conditional note about purchased full text gives some context, but no direct when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest price data for one tokenized stock: mid price, day high and low, volume and whether trading is halted.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker, for example AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint and openWorldHint already establish the safety profile. The description adds the data fields and the halted-trading flag, which is useful, but it does not disclose freshness, error behavior, or any additional operational constraints. No contradiction.
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 sentence with the most important information front-loaded, followed by a compact list of return fields. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only quote tool with no output schema, the description lists what the response contains and is sufficient for basic invocation. It could add a note on currency or error handling, but these are 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?
Schema description coverage is 100% and the symbol parameter already includes an example (AAPL). The description adds only the 'tokenized stock' context, not new parameter semantics, so a 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 names the resource (one tokenized stock) and the payload (mid price, day high/low, volume, halted flag), with the title supplying the verb 'Get'. This distinguishes it from siblings like list_stocks, which cover all stocks.
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?
'For one tokenized stock' makes the intended call pattern clear, and a single symbol parameter is required. It does not explicitly state when not to use this tool or name a sibling alternative, but the scope itself is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List live presses, newest first, with the free preview, price in USDG, AI audit score, votes and read count. Optionally filter by stock ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return. Defaults to 20. | |
| stock | No | Ticker of a tokenized stock, for example NVDA. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds behavioral details beyond annotations: ordering ('newest first') and the specific fields included in the response. It also notes the optional stock filter. This provides useful context without contradiction.
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, compact sentence that front-loads the action and key output fields, followed by the optional filter. No wasted words; every element earns its place. It is efficiently structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing the return payload, and it does so by listing the fields (preview, price, audit score, votes, read count) and ordering. It does not mention pagination or the default limit (though that is in the schema). For a read-only list with two optional params, this is largely 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?
Both parameters (limit, stock) are fully described in the input schema (100% coverage). The description mentions the stock filter but adds no new meaning beyond the schema's description ('Ticker of a tokenized stock'). It does not elaborate on limit or its default, which the schema already covers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List live presses') and specifies the fields returned (free preview, price in USDG, AI audit score, votes, read count). It distinguishes from siblings like get_press (single vs list) and read_purchased (purchased vs all), but does not explicitly name an alternative. The verb 'list' and resource are specific enough for an agent to infer the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing all live presses, optionally filtered by stock ticker. It gives a clear conditional ('Optionally filter by stock ticker') but does not explicitly contrast with alternatives like get_press for a single press or read_purchased for purchased ones. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tokenized stocks a press can be about, with ticker, company name and token address on Robinhood Chain.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Filter by ticker or company name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds context about the chain and return fields but does not disclose additional behavioral traits such as pagination, limits, or ordering. This is adequate but minimal for a simple read-only 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 a single compact sentence with no filler or redundant content. It front-loads the core subject and packs useful return-field details efficiently.
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 read-only list tool with one optional parameter and no output schema, the description conveys the domain and return fields while annotations cover side-effect safety. It is complete enough for a call, though it does not mention ordering, limits, or pagination.
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 single optional 'search' parameter is fully documented in the schema as filtering by ticker or company name. The description mentions those same fields but adds no new semantics beyond the token address in the output. With 100% schema description coverage, the 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 identifies the resource as tokenized stocks and names the returned fields (ticker, company name, token address on Robinhood Chain), which distinguishes it from sibling tools like list_presses. However, it lacks an explicit verb such as 'lists' or 'returns'; the action is only present in the title.
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 phrase 'a press can be about' provides context for when this stock list is relevant, but it does not explicitly say when to use this tool over siblings or when not to use it. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read from the local library of presses this wallet bought. Without arguments it lists them. With a pressId it returns the full text. Free and offline.
| Name | Required | Description | Default |
|---|---|---|---|
| pressId | No | The press to read. Leave out to list everything saved. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by noting it is free and offline and that omitting pressId lists everything. It does not detail return format or behavior for invalid pressId, but the read-only annotation covers the main safety profile.
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 short sentences, front-loaded with the core purpose, then mode distinction, then key constraints. 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?
For a simple read-only tool with one optional parameter and no output schema, the description covers the main usage modes and constraints. It could mention what happens if pressId is not found, but that is a minor gap given the simplicity.
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%, so the schema already documents pressId. The description adds the behavioral meaning of omitting it (list everything) and that with it returns full text, which is useful but not extensive.
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 reads from the local library of purchased presses, distinguishes the two modes (list all vs. read full text by pressId), and explicitly notes it is free and offline. This differentiates it from siblings like get_press or list_presses.
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 explains when to use it: to read purchased presses, with or without a pressId. It does not explicitly name alternatives or exclusions, but the context of 'this wallet bought' and 'free and offline' implies when it is appropriate versus other press tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cast an onchain vote on a press: up or down, with an optional tag. The vote goes to the reputation registry on Robinhood Chain and costs a little ETH for gas. A new vote from the same wallet replaces the old one. Votes by the publisher on their own press are not counted.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Why. Optional. | |
| slug | No | The slug of the press. Use this or pressId. | |
| vote | Yes | up is +1, down is -1. | |
| pressId | No | The onchain id of the press, as returned by list_presses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=false), the description discloses that the vote costs ETH for gas, that a new vote from the same wallet replaces the old one, and that publisher self-votes are not counted. This materially reduces the agent's uncertainty about side effects. No contradiction with annotations.
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 sentences, each adding distinct value: the action, the cost/replacement, and the self-vote exclusion. The core action is front-loaded, and there is no filler.
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 output schema, the description covers the critical behavioral facts (gas cost, replacement, self-vote discount) and the schema covers press identification and vote semantics. It could state what the call returns (e.g., transaction hash) and that exactly one of slug/pressId is needed, but those gaps are minor given a 100%-coverage schema.
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%, so the schema already documents vote, tag, slug, and pressId including the 'up is +1, down is -1' semantics and the slug-or-pressId hint. The description adds no parameter-level detail beyond what the schema provides, so it meets the baseline for high 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 opens with a specific verb and resource ('Cast an onchain vote on a press: up or down, with an optional tag'), which cleanly distinguishes it from siblings like buy_press and get_press. It also adds the 'reputation registry on Robinhood Chain' context, making the purpose unmistakable.
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 clear usage context: onchain action, gas cost, replacement behavior, and self-vote exclusion – all of which signal when and how to use the tool. It does not name explicit alternative tools, but no sibling offers a voting function, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The agent wallet's address, ETH and USDG balances on Robinhood Chain, whether the one-time USDG approval is done, the spend cap per press, and how many presses are saved locally.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and openWorldHint annotations already cover the safety profile, and the description adds useful context beyond them: it indicates the data source (Robinhood Chain), the existence of a one-time approval state, and that press counts are stored locally. This is meaningful behavioral context for an agent.
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 sentence delivers a complete list of the tool's outputs with no filler or repetition. Every clause carries distinct information, and the most identifying detail (wallet address) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, and it does so thoroughly: address, balances, approval status, spend cap, and saved press count. For a zero-parameter status tool, nothing essential is missing.
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 tool has zero parameters and 100% schema coverage, so there are no parameter details for the description to add. The baseline of 4 applies because the parameter dimension is effectively non-issue.
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 identifies a read-only wallet status tool and enumerates exactly what it reports: address, ETH/USDG balances, approval state, spend cap, and saved press count. This is a specific verb-less but unambiguous status definition that distinguishes it from siblings like vote_press or 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?
The contents imply this is the tool to call when the agent needs current wallet or approval information, but the description does not explicitly state when to prefer it over alternatives such as approve_usdg or buy_press. Usage context is understandable but not made explicit.
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.0agent_guideapprove_usdgbuy_pressget_pressget_quotelist_presseslist_stocksread_purchasedvote_presswallet_statusScored across 10 tools
Most tools target distinct resources and actions: reading purchased content, voting, browsing presses, viewing stock quotes, wallet status, and buying. Minor overlap exists between read_purchased and get_press since both can return full text for owned presses, but their primary intents are clearly separated.
The majority of tools follow a clean verb_noun pattern (list_presses, get_quote, buy_press, approve_usdg). Two tools, agent_guide and wallet_status, are noun phrases rather than verb_noun, creating a slight deviation but not enough to cause confusion.
Ten tools is well-scoped for a press marketplace with wallet integration. Each tool covers a necessary function—discovery, purchasing, reading, voting, stock data, and wallet setup—without redundancy.
The core lifecycle is covered: discover presses, inspect details, buy, read purchased content, and vote. Missing search across presses beyond ticker filtering and there is no mechanism to manage or revoke votes, but these are minor gaps that do not break typical workflows.
Prediction-market news, $0.01/query. Register and buy inside this MCP session — free testnet funds.
Remote MCP server exposing 330 production AI-agent services for web/data processing, validation, AI utilities, blockchain/crypto utilities, and x402 pay-per-use access.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Publish, search, and promote time-sensitive news and messages through a public remote MCP server.
