Loading ToolBench
MCP server exposing a Ramestta AI agent's on-chain capabilities as tools for Claude and other MCP clients
Server exposes 6 blockchain-focused tools with basic schemas and descriptions. All tools have names starting with action verbs (ramestta_*) and descriptions present. However, parameter descriptions are minimal or absent, most parameters lack detail on format, constraints, or expected values. No output schemas documented. Error handling guidance is absent. Tool descriptions are adequate (50-100 chars) but lack context on when to use each tool vs. alternatives. Parameters like 'to' in ramestta_send_payment and 'callDataHex' in ramestta_schedule_task lack format/constraint documentation. No mention of idempotency, retry behavior, or recovery paths for failures.
Get the agent's .rama name, wallet address and RAMA balance.
List the agent's scheduled task ids.
Sponsored (gas-free) transactions left this month.
Schedule a recurring on-chain call, executed by the keeper market (no server needed).
Send an end-to-end encrypted message to another agent by .rama name.
Send RAMA to an address or .rama agent name (respects on-chain spend limits).
Parameter descriptions missing or incomplete. 'to' in ramestta_send_payment lacks format guidance (address vs .rama name handling). 'callDataHex' in ramestta_schedule_task has no explanation of encoding or validation. 'everySeconds' lacks min/max bounds. LLMs cannot infer constraints from names alone.
No output schemas documented. Callers cannot know what fields to expect from ramestta_agent_info (does it return balance as string or number?), ramestta_remaining_quota (quota count? remaining gas?), or ramestta_list_tasks (task IDs only, or full task objects?). Forces LLMs to guess downstream field names.
No error handling guidance. Tools that modify state (ramestta_send_payment, ramestta_schedule_task, ramestta_send_message) do not document failure modes, recovery steps, or whether operations are idempotent. An LLM retrying a failed payment has no way to know if it will double-charge.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Parameter type hints incomplete. 'everySeconds' is typed as number but lacks min/max bounds. 'amountRama' is string but no format specified (decimal places? scientific notation?). 'callDataHex' is string but no validation that it is valid hex. Unbounded or unvalidated inputs invite hallucinated values.
Tool descriptions lack context on when to use each tool vs. alternatives. 'Send RAMA to an address or .rama agent name' does not explain the difference in behavior, gas costs, or prerequisites. No guidance on calling ramestta_remaining_quota before ramestta_send_payment to check limits.