MCP server for Run402 — full-stack backend infrastructure for AI agents: Postgres, auth, storage, serverless functions and atomic deploys. Paid with x402/MPP. Includes $0.03 image generation.
This MCP server has fundamental quality gaps across naming, descriptions, parameter documentation, and error handling. While 10 tools are defined, most lack adequate descriptions and comprehensive parameter schemas. The naming is partially verb-driven but some tools are ambiguous (e.g., 'init', 'tier_set'). Parameter schemas are minimal, most tools accept only 1-2 simple string/number parameters with sparse documentation. Output schemas are not visible in the provided code. Error handling guidance is absent. The server targets a specialized domain (Run402 financial/infrastructure platform) but does not follow the 54 Agentic Tool Patterns for production-grade agent tooling.
Output schemas are not documented in the provided code for any tool. LLMs cannot infer what data structure each tool returns, preventing downstream tool chaining and context planning.
Most input parameters lack validation constraints. String parameters like 'code', 'tier', 'address', 'projectName' have no enum values, regex patterns, length limits, or format documentation. This invites hallucinated invalid input from LLMs.
Naming lacks clarity in several tools. 'init' is too generic and does not convey 'create/initialize project'. 'lightning_wallet' is missing the verb (should be 'access_lightning_wallet' or 'get_lightning_wallet_balance'). These names reduce LLM signal for tool selection.
Recommendations
Add comprehensive output schemas to every tool. Document return types, field names, and structure. Example for 'check_balance': { 'balance': { 'type': 'number', 'description': 'Current balance in the account' }, 'currency': { 'type': 'string', 'enum': ['sats', 'msat', 'usd'], 'description': 'Currency of the balance' }, 'timestamp': { 'type': 'string', 'format': 'date-time' } }.
Replace free-form string parameters with enums. For 'tier_set', replace the 'tier' parameter with an enum: { 'type': 'string', 'enum': ['free', 'starter', 'pro', 'enterprise'], 'description': 'The tier level to set' }. For 'redeem_voucher', document expected code format (e.g., 'alphanumeric 10-20 characters').
Rename 'init' to 'create_project' or 'initialize_project' to be more explicit about the action and resource. Rename 'lightning_wallet' to 'get_lightning_wallet_balance' or 'access_lightning_wallet_info' to include a clear verb.
Expand descriptions to 100-150 characters. Example for 'check_balance': 'Check your current account balance. Returns the balance amount, currency type, and last update timestamp. Use this before financial operations to confirm available funds.'
Add error handling guidance to every tool. Document common failure modes and recovery actions. Example: 'allowance_create will fail if the amount exceeds your current balance. If rejected, call check_balance() first, then request_faucet() if needed.'
Document tool dependencies and call order. Create a diagram or table showing which tools depend on others. Example: 'init -> allowance_create -> check_balance' or 'request_faucet -> check_balance'. Include in tool descriptions.
Error handling and recovery guidance is absent. No documentation of what errors each tool can return, what they mean, or what the LLM should do next (retry? ask user? try alternative tool?). This violates the recovery-guide pattern.
Descriptions are too brief and lack contextual detail. Many are under 70 characters and do not explain WHEN to use the tool, WHAT it depends on, or WHAT it returns. Example: 'Check account balance' does not specify which account (main? allowance? wallet?).
Tool composition is unclear. Many tools operate on the same domain (allowance, wallet, tier) but their relationships are not documented. For example, does 'init' need to be called before 'allowance_create'? Does 'check_balance' return the same currency as 'request_faucet' uses?
Financial/transactional tools (allowance_create, request_faucet, redeem_voucher) lack confirmation or dry-run patterns. These are destructive or irreversible operations, LLMs should be able to preview before committing.
allowance_createrequest_faucetredeem_voucher
Add validation ranges and constraints to numeric parameters. For 'allowance_create', specify: { 'amount': { 'type': 'number', 'minimum': 0.001, 'maximum': 10000, 'description': 'Amount in the platform currency (sats or USD equivalent). Range: 0.001 - 10000.' } }.
Implement confirmation patterns for financial operations. Add optional 'dry_run' or 'confirm' parameters to allowance_create, request_faucet, and redeem_voucher. Return a preview/confirmation ID before executing, then accept a second call with confirmation_id to finalize.
Clarify financial semantics. Document what 'allowance' means, whether it is separate from 'balance', and how they interact. Specify currencies and exchange rates. Example: 'An allowance is a spending limit for automated agent actions. It is deducted from your main balance when used.'
Add idempotency guidance. For tools that create resources (init, allowance_create), document whether repeated calls with the same parameters return the same result or fail. If idempotent, include an idempotentHint in the tool definition.
Provide discovery/list tools. Add 'list_tiers' or 'describe_tiers' to let LLMs discover valid tier options. Add 'list_allowances' to view existing allowances before creating new ones.