r0x-os

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation4/5
Most tools have distinct purposes (balance vs. fund, send vs. trade), but wallet and r0x_setup overlap slightly, and quote/pool both provide price-related data. Descriptions are clear enough to guide an agent.
Naming Consistency3/5
All tool names are lowercase with underscores, but the style mixes nouns (balance, price, pool) and verbs (send, broadcast, trade). Compound names like liquidity_add and spend_limit are inconsistent with simple verb-first patterns, making the set feel somewhat uneven.
Tool Count4/5
18 tools cover a broad DeFi and chain-introspection surface without being excessive. The count is slightly above the ideal 3-15 range but is justified by the diversity of operations (swaps, liquidity, bridge, yield).
Completeness3/5
Core functions like transfers, swaps, liquidity management, and balances exist, but balance only supports ETH/USDG despite any-token swaps. Bridge is quote-only, and there is no arbitrary-token balance or transaction history tool, leaving notable gaps for agents.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 62 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the $0.01 USDG cost, which is a significant behavioral trait. However, with no annotations provided, it lacks any mention of rate limits, caching, or whether the operation is read-only, though that is implied. It also does not describe the response format.
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 extremely concise with two short sentences that convey the core function and cost without any unnecessary detail. It is front-loaded and easy to parse.
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 price-check tool, the description covers the purpose and cost, but it does not specify the return type or any API-specific details like error conditions. Given no output schema, the absence of return-value information leaves a gap, though the tool is otherwise simple enough to operate.
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 merely restates the enum values (ETH, USDG) already present in the schema, adding no new meaning. Since schema coverage is 0%, the description was expected to compensate, but it only repeats what the schema provides.
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 that the tool provides the current USD price for ETH or USDG, which is a specific function that distinguishes it from sibling tools like quote or trade. The scope is explicit and immediately understandable.
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 instead of alternatives like quote or trade, nor are there exclusions or prerequisites. The description only states the purpose and cost, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the $0.01 USDG cost and indicates it returns balance plus instructions, but it does not specify output structure, potential side effects, or whether it actually executes a funding transaction.
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 two short sentences, front-loading the core purpose ('Balance plus step-by-step funding instructions') and adding the critical cost caveat. No wasted words.
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 one-parameter read/advice tool with no output schema, the description covers the main context: target address, what to expect (balance + instructions), and cost. It lacks explicit output formatting and edge-case detail, but is minimally viable for agent invocation.
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?
The single 'address' parameter is defined in the schema by regex, and the description adds that this is a Robinhood Chain address, clarifying the network. However, with 0% schema coverage in the description, it does not fully compensate by explaining what the address should represent beyond the property name.
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?
The title 'Check funding status' and description 'Balance plus step-by-step funding instructions for a Robinhood Chain address' clearly state the tool's verb and target resource. It distinguishes itself from the 'balance' sibling by adding funding instructions, though it does not explicitly name alternatives.
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 use when a user needs balance and funding instructions for a Robinhood Chain address, and the cost warning adds context. However, it provides no explicit when-to-use/when-not-to-use guidance or references to sibling tools like 'balance' or 'r0x_setup'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a cost of $0.01 USDG and notes it works for any address, which is useful. However, it doesn't mention whether it's a read-only operation (though obvious), how invalid addresses are handled, or any other side effects, so it's only partially transparent.
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 two short sentences, front-loaded with the main purpose and cost, with zero redundancy. Every word earns its place.
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?
For a simple one-parameter tool with no annotations or output schema, the description covers the core purpose, cost, and address scope. It lacks return format details, but the tool's simplicity makes this less critical. Could benefit from a brief note on expected output, but the essentials are present.
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?
The schema has no parameter descriptions, so the description's mention of 'any Robinhood Chain address' adds semantic context to the 'address' parameter. However, it doesn't explicitly map the parameter to its meaning beyond that, and the schema pattern already dictates the format. Minimal compensation for the 0% schema coverage.
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 states exactly what the tool does: checks ETH and USDG balance for any Robinhood Chain address. This clearly differentiates it from sibling tools like 'wallet' by specifying the asset types and address scope.
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 usage is implied—you'd use this tool to check a balance—but there is no explicit guidance on when to prefer it over alternatives like 'wallet' or 'tx'. No exclusions or alternative references are provided, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does disclose a key behavioral trait: the cost of $0.01 USDG. However, it does not mention any potential side effects, prerequisites (e.g., setup), or error behaviors, leaving some transparency gaps for a chat tool.
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, efficient sentence that conveys the action, target, result, and cost with no redundant words. It is perfectly sized for the tool's simplicity.
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?
For a low-complexity tool with one parameter and no output schema, the description is reasonably complete. It states what it does, the result, and importantly notes the cost. It could be improved by mentioning whether setup is required or what happens on failure, but these are minor omissions given the trivial nature of the operation.
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?
The only parameter 'message' has no schema description (0% coverage), but the tool description itself says 'Sends a message', which directly connects the message parameter to its purpose. It adds some meaning, but not much beyond the parameter name; it does not specify format or constraints.
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 'Sends' and the resource 'a message to the r0x agent', along with the outcome 'returns its reply'. This unambiguously differentiates it from sibling tools, which are all financial operations.
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 you want to communicate with the r0x agent. It does not explicitly state when to use this tool over alternatives or mention any prerequisites, but the distinct purpose compared to siblings makes the use case implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost ($0.01 USDG) and the 'decoded' nature of the output, but does not mention authentication, error cases, rate limits, or whether it is strictly read-only beyond the 'look up' verb.
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 two sentences, front-loaded with the core purpose and immediately followed by the cost. Every word earns its place with no redundancy.
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?
The tool is simple with one parameter and no output schema, so the description should explain what 'decoded transaction details' contains. It does not specify fields like status, sender, recipient, value, or gas, leaving the return value under-specified.
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 0%, so the description must compensate. It adds meaning by clarifying that the 'hash' parameter is a Robinhood Chain transaction hash, but it does not provide examples or additional details beyond what the pattern already implies.
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 title 'Look up a transaction' and description 'Decoded transaction details for any Robinhood Chain tx hash' clearly state a specific action on a specific resource. It distinguishes itself from sibling tools like broadcast or send by focusing on reading/decoding transaction details.
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?
The description clearly implies the use case: when you need decoded details for a Robinhood Chain transaction hash. It does not explicitly name alternatives or exclusions, but the context is unambiguous among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the cost and the fact it's a quote, implying a read-only operation, but does not explicitly state that no execution occurs or provide other behavioral details like idempotency or error handling. This is moderate disclosure.
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 the essential purpose ('Across Protocol bridge quote') followed by key specifics (tokens, chains, cost). No filler or redundant information.
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?
For a simple quote tool with 3 params and no output schema, the description provides essential context: purpose, supported chains/tokens, destination, and fee. It lacks explicit output format or a note that it does not execute the bridge, but these are minor gaps for a quote tool.
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?
The schema already describes originChainId and amount, and token has an enum. The description adds the destination (Robinhood Chain) and confirms the supported chains/tokens, but does not add deeper meaning for individual parameters beyond what the schema provides. With 67% schema coverage, the description partially compensates but not fully.
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 names a specific protocol (Across Protocol), a clear action (bridge quote), the supported tokens (USDC/WETH), origin chains (Ethereum, Arbitrum, Base), destination (Robinhood Chain), and cost ($0.01 USDG). This is a specific verb+resource+scope that distinguishes it from the sibling 'quote' tool.
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?
The description clearly implies this tool is for bridging assets from the listed chains to Robinhood Chain, providing contextual usage. It does not explicitly contrast with the sibling 'quote' tool or state exclusions, but the specificity of the bridge context makes it easy to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses a notable cost ($0.01 USDG), which is important for an AI agent to know before invocation. It also specifies the output contents (tick range, liquidity, uncollected fees), adding transparency beyond a generic 'list' statement.
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 sentence that front-loads the action and resource. It includes the cost detail and output fields without wasted words, making it highly concise and well-structured.
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?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the key aspects: what it lists, for whom, and at what cost. It does not mention pagination or error behavior, but these are not critical for a basic read-only lookup tool with a well-defined single parameter.
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%: the single address parameter is already described with type and format ('Robinhood Chain address to look up (0x...)'). The description adds no extra semantic detail beyond the schema, so it meets the baseline but does not exceed it.
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 uses a specific verb 'Lists' and clearly identifies the resource: 'Uniswap V3 liquidity position NFT owned by an address on Robinhood Chain'. It also specifies the data returned (tick range, liquidity, uncollected fees), which distinguishes it from sibling mutation tools like liquidity_add and liquidity_remove.
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 the tool is for viewing an address's liquidity positions but does not explicitly state when to use it versus alternatives or provide exclusions. It is clear enough for a simple read operation but lacks explicit guidance about sibling tools like liquidity_add or liquidity_remove.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a fee ($0.01 USDG) and the read-only nature implicitly via 'pool reserves and implied price'. It also explains input flexibility ('ETH', 'USDG', or any ERC20 address). Missing details like error behavior are minor for a simple query tool.
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, well-structured sentence that front-loads the primary function, provides example inputs, and mentions the cost. Every word adds value with no redundancy.
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?
Given the tool's simplicity and lack of output schema, the description sufficiently covers what the user can expect: pool reserves and implied price. It also includes the cost and chain context. Minor omissions like return format are acceptable for this straightforward read-only tool.
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 tokenA and tokenB both described as 'ETH', 'USDG', or any ERC20 address. The description adds only the context that they form a token pair, which is a small semantic addition beyond the schema. Baseline 3 is appropriate.
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?
The description clearly states the tool's function: it provides Uniswap V3 pool reserves and implied price for a token pair. While it doesn't explicitly differentiate from sibling tools like 'price' or 'quote', the specific mention of pool reserves makes the purpose distinct.
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?
The description gives clear context for use: 'any token pair on Robinhood Chain' and notes a cost of $0.01 USDG, which informs cost-sensitive usage. However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It mentions local generation, no payment, storage path, and reuse by other tools. However, it does not disclose what happens if the wallet already exists (overwrite behavior), whether import also requires payment, or security aspects of storing the private key—gaps that matter for a setup tool.
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 only two sentences long, front-loads the core purpose ('One-time setup'), and contains zero fluff. Every word adds value, making it highly efficient.
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?
Given the tool's simplicity (2 params, no output schema), the description is nearly complete: it covers purpose, modes, storage, and reuse. The only missing piece is clarification of re-running behavior (whether it overwrites an existing wallet), which is relevant for a 'one-time' setup tool. This minor gap prevents a perfect score.
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?
The input schema already provides 100% description coverage for both parameters, including the enum for mode and the pattern for privateKey. The description adds the context of one-time setup and the 'no payment required to generate' note, but these are optional extras rather than essential semantic clarifications, so the baseline 3 is appropriate.
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 purpose: one-time setup for the r0x plugin, with two specific modes (import or generate). It distinguishes from all sibling tools, which are transaction/query tools, by being the setup prerequisite.
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?
The description implies when to use this tool via 'One-time setup' and 'reused by every other r0x tool,' indicating it should be run before other r0x operations. It also explains the two modes, but does not explicitly say when to choose one over the other or list any alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses 'Local-only safety guard, never touches the server', which is a key behavioral trait. It also scopes to this session. However, it does not state whether setting the cap enforces blockages when exceeded or what happens on reset, leaving some behavioral ambiguity.
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 three short sentences, front-loading the most distinctive trait (local-only) and ending with a simple usage tip. No 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?
For a simple two-parameter tool with no output schema, the description is fairly complete: it states the purpose, the local scope, and the read/write semantics. It lacks explicit return-value information and enforcement consequences, but these are not critical for basic usage.
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?
The input schema already describes both parameters fully (100% coverage), so the baseline is 3. The description adds minimal extra value: it repeats that omitting setUSD checks status, but does not mention reset or provide additional syntax details beyond the schema.
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 states a specific verb-resource pair: 'Reads or sets a USD cap on total spend across all paid r0x tools in this session.' It also adds the unique local-only nature, distinguishing it from server-side tools. This is a clear, specific statement of purpose.
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?
The description gives clear context: it is a local-only safety guard for the session, and explains the read vs. set behavior ('Omit setUSD to just check status'). However, it does not explicitly mention alternatives or when-not to use, though the uniqueness of the tool makes that less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently states that the transaction is unsigned, that it costs $0.01 USDG, and that broadcasting is required to send—critical behavioral traits. It does not, however, describe the return format or error conditions, which would have made it fully transparent.
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 exactly three sentences, front-loaded with the core action, followed by cost and workflow in a logical order. Every sentence contributes essential information with no redundancy or filler.
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?
For a simple 3-parameter tool with no output schema, the description covers the key aspects: what it does, the cost, and the next step. It misses the return value structure, but the instruction to 'pass the result' implicitly acknowledges a result exists. Overall, it is nearly complete for the tool's complexity, though not exhaustive.
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 description coverage is only 33% (only 'amount' has a description). The tool description does not add meaning beyond the schema—it merely repeats the token enum values (ETH, USDG) already present in the schema. It fails to explain 'to' address format or the relationship between amount and cost, leaving the agent under-informed about parameter usage.
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: 'Constructs an unsigned ETH or USDG transfer transaction on Robinhood Chain.' It names the specific verb (constructs), resource (transfer transaction), and asset types (ETH/USDG), and distinguishes from sibling tools like broadcast (which signs and sends) and trade.
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?
The description provides context on the intended workflow by saying 'Pass the result to the broadcast tool to actually sign and send it,' which implies when to use this tool vs. broadcast. However, it stops short of explicitly stating when not to use this tool or naming alternatives like trade or bridge, leaving some ambiguity for broader use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behavioral traits: it is live, non-transactive ('no transaction constructed'), and incurs a cost of $0.01 USDG. This goes beyond simple purpose and helps the agent understand safety and side effects, though it doesn't cover return format or error behavior.
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, information-dense sentence that front-loads the purpose, then adds cost and non-transaction behavior. Every word earns its place with no redundancy or filler.
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?
For a simple quote tool with no output schema, the description covers the essential context: chain, token formats, cost, and non-execution. It does not specify the exact response shape, but 'swap price quote' implies the returned value. Given the tool's simplicity and the schema covering parameters, this is sufficiently complete, though a mention of output would push it to 5.
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 100%, so the baseline is 3. The description adds only minimal clarification by repeating the accepted token formats ('ETH', 'USDG', or ERC20 address'), which the schema already documents. It does not add meaningful new meaning beyond the schema.
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 provides a 'Live Uniswap V3 swap price quote for any token pair on Robinhood Chain', which specifies the verb (get/quote), resource (swap price quote), and scope (Uniswap V3, Robinhood Chain). It also differentiates from siblings like 'trade' by explicitly noting 'no transaction constructed'.
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?
The description gives clear context for when to use the tool: for getting a quote rather than executing a transaction. It states 'no transaction constructed', which implicitly tells the agent this is the quoting alternative to a trade tool. However, it does not explicitly name alternatives or provide exclusion criteria, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions the live nature of the data and the $0.01 USDG cost, which is valuable. However, it doesn't state whether the call is read-only or what the return format looks like (e.g., percentage as decimal), leaving some transparency gaps.
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 extremely concise: two sentences with the core value proposition and cost front-loaded. Every word adds essential information, and there is no unnecessary elaboration.
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?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential purpose and cost. It also provides useful context about the vault's relationship to Robinhood Earn. However, it could explicitly mention the expected return format (e.g., APY as a percentage) and confirm it's a read-only operation, though neither is critical.
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 zero parameters, so the description adds no parameter-specific information. The schema coverage is trivially 100%, and the baseline for no parameters is 4. The description's mention of the vault and cost is not parameter-related but doesn't reduce the score.
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 provides 'Live Morpho steakUSDG vault APY' with additional context about it being behind Robinhood Earn. The title 'Check USDG yield' reinforces the purpose. This distinguishes it from sibling tools like 'price' or 'balance' by specifying the exact resource (yield/APY) and vault.
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?
The description implies usage for checking the APY of the specific Morpho steakUSDG vault and discloses a cost of $0.01 USDG, which helps the agent decide if this tool is appropriate. It doesn't explicitly state when not to use it or mention alternatives, but the specificity of the resource makes the usage scenario clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the operation costs $0.01 USDG, defaults to a configured wallet if no private key is given, and moves real funds (a strong warning). It does not describe failure handling or return values, but the core behavioral traits are covered.
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?
Three sentences, each adding essential information: the core action, the cost, and the default/risk warning. No irrelevant details or repetition.
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 tool is simple, but with no output schema, some return-value detail would be helpful. The description covers the input source, cost, default key behavior, and caution, which is largely complete for a broadcast operation. Missing explicit return hash or confirmation behavior, but not critical.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by tying the 'tx' parameter to the send tool's output and clarifying that 'privateKey' is optional with a default wallet, which goes beyond the schema's basic descriptions.
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 specific function: signs an unsigned transaction from the send tool and broadcasts it on Robinhood Chain. This distinguishes it from the send tool (which produces the unsigned transaction) and other sibling tools.
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?
The description implies when to use it—after the send tool produces an unsigned transaction—and notes the default wallet behavior. It lacks an explicit 'do not use when' or direct alternative names, but the prerequisite relationship with the send tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers well. It discloses the cost ($0.01 USDG), the automatic WETH unwrapping behavior, and the crucial fact that it returns unsigned steps requiring further broadcast. These are non-obvious behaviors an agent must know to use the tool correctly.
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, front-loaded with the purpose, and every sentence adds essential information: what it does, the cost, a key edge-case behavior, and the required follow-up action. There is no fluff or repetition of schema content.
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?
For a tool with only two parameters and no output schema, the description covers the critical context: the source of tokenId, the cost, the auto-unwrap, and the need to broadcast results. It doesn't cover error cases or what happens if the position is invalid, but the essential workflow is well explained.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that tokenId should come from liquidity_add or liquidity_positions, providing context not present in the schema. It doesn't elaborate on the burn parameter, but the schema already describes it sufficiently.
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 identifies the specific action: 'Withdraws and collects a Uniswap V3 liquidity position on Robinhood Chain by tokenId'. It also distinguishes this from related sibling tools by referencing the source of tokenId ('from liquidity_add or liquidity_positions') and the downstream broadcast tool, making its role in the workflow explicit.
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?
The description provides clear usage context: the tokenId comes from liquidity_add or liquidity_positions, and the result should be passed to the broadcast tool for signing. It doesn't explicitly state when not to use this tool or compare it to alternatives, but the workflow guidance is strong enough to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It discloses the real transaction nature, the $0.01 USDG cost, the step-based response for approvals, and the dependency on the broadcast tool. These are meaningful behavioral traits beyond the schema.
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?
Four sentences, each earning its place: purpose, cost, approval workflow, and next step. Information is front-loaded and there is zero redundancy. Ideal conciseness.
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 explains the core workflow (construct, approve if needed, broadcast), cost, and token flexibility. Given the absence of an output schema, it adequately describes what the tool returns (steps). It could be more explicit about the structure of steps or failure modes, but it is sufficient for the task.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that any ERC20 address works (no allowlist), that amount is a decimal string, and that approval steps may be returned. This enhances understanding of how parameters behave in context.
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 constructs a real Uniswap V3 swap transaction between any two tokens. It distinguishes itself from sibling tools like price/quote (which likely just quote) and broadcast (which actually signs/sends). The explicit mention of 'pass the result to the broadcast tool' further clarifies its role.
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?
The description gives clear usage context: any two tokens, no allowlist, and the workflow of passing results to broadcast. It implies when to use (for swaps) and how to handle outputs with steps. However, it does not explicitly mention when to use alternative tools like quote/price for price checks, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the cost ($0.01 USDG) and that generation occurs server-side via a facilitator. However, it does not describe the return format or any side effects beyond creating a keypair, leaving some behavioral ambiguity.
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 wasted words. The first sentence states the core action, the second provides cost and an alternative. Everything earns its place, and the most important 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?
For a simple no-parameter tool, the description covers the what, the cost, and an alternative. However, absence of an output schema means the description should clarify what is returned (e.g., public key, private key, mnemonic), which is missing. Otherwise it is quite complete.
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?
The tool has zero parameters, so there is no schema to add meaning. The description adds relevant context about cost and server-side execution, which is useful context for invocation, though no parameter details are needed.
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 it generates a fresh Robinhood Chain keypair via the r0x facilitator. The verb 'generates' and resource 'keypair' are specific, and it distinguishes itself from sibling r0x_setup by noting the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For your own agent wallet, prefer the free local generation in r0x_setup instead,' providing a clear exclusion and naming the alternative. Also conveys the context of server-side generation and the associated cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it mentions the $0.01 USDG fee, that amounts are maximums rather than exact pulls, and that the tool returns a sequence of steps (approvals then mint) that must be broadcast in order. This goes well beyond what the schema alone conveys.
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 three sentences, each adding value: purpose, fee/max behavior, and output flow. It is front-loaded with 'Mints a Uniswap V3 liquidity position' and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a DeFi tool with no output schema, the description covers all critical aspects: action, cost, amount semantics, and the necessary follow-up (broadcasting steps). It provides enough context for an agent to understand the tool's role and dependencies without needing additional explanation.
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?
Although the schema covers 100% of parameters, the description adds crucial meaning to amountA/amountB by explaining they are maximums and that the contract only pulls what the range needs. It also ties rangePct to the 'custom price range' concept, enriching the schema descriptions.
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 states a specific verb and resource: 'Mints a Uniswap V3 liquidity position for any token pair on Robinhood Chain, with a custom price range.' It clearly distinguishes this from sibling tools like liquidity_remove and liquidity_positions, which handle different actions.
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?
The description provides clear context for when to use this tool (to add liquidity) and gives workflow guidance by explaining that the output is steps to be broadcast via the broadcast tool. It does not explicitly contrast with alternatives, but the purpose is self-evident and the broadcast dependency is a clear usage instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![project-r0x MCP server](https://glama.ai/mcp/servers/nhevers/project-r0x/badges/card.svg)](https://glama.ai/mcp/servers/nhevers/project-r0x)

Score Badge

Copy to your README.md:

[![project-r0x MCP server](https://glama.ai/mcp/servers/nhevers/project-r0x/badges/score.svg)](https://glama.ai/mcp/servers/nhevers/project-r0x)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nhevers/project-r0x'

If you have feedback or need assistance with the MCP directory API, please join our Discord server