This MCP server exposes 15 tools but critically lacks visible parameter schemas and comprehensive descriptions. Analysis of available source code (lib/indexter-tool-result.mjs, lib/open-tool-auth.mjs) reveals tool names and basic descriptions but NO explicit JSON Schema definitions are visible in the provided code sample. Per the hard rules, without visible input schemas, schema scores must be 0. Tool descriptions are present but minimal (10-60 characters), falling well below the 194-character baseline and 50-200 character LLM-optimized range. The server appears to delegate tool execution to external services (@dexterai/x402-mcp-tools, @dexterai/vault) but does not expose their parameter contracts in the source shown. This violates the foundational pattern:tool requirement that every parameter must be documented with type and description. The crypto/DeFi domain introduces irreversible operations (asset execution, wallet reconciliation) that require explicit error handling and confirmation patterns, absent from descriptions. Naming follows a reasonable verb_noun pattern (index_*, x402_*, dexter_*) but parameter-level validation constraints are not visible.
NO visible input schemas for any of 15 tools. Hardcoded rule: schema score must be 0 when schemas are not visible in source. This blocks LLMs from understanding parameter types, ranges, and constraints.
Tool descriptions are 10 - 60 characters, far below the 194-character baseline and 50-200 character LLM-optimized range. Descriptions lack WHEN to use, WHAT it returns, and any prerequisites. This prevents LLMs from correctly selecting tools when many alternatives exist.
Register all 15 tools with explicit, complete JSON Schema input definitions. Include type (string|number|boolean|object|array), format (email|uuid|date-time), constraints (minLength, maxLength, pattern, enum), and whether each parameter is required or optional.
Expand ALL tool descriptions to 100 - 200 characters minimum. Answer: WHAT does it do? WHEN should the LLM use it vs. similar tools? WHAT does it return? Example: 'indexter_discover' → 'Discover available tools and resources by querying indexter host manifests. Use this first to learn what tools/resources are available before calling search_*. Returns a list of tool/resource names, descriptions, and access URLs.'
Add comprehensive parameter descriptions to EVERY parameter. For each parameter, state: name, type, format, constraints (range/enum), whether it's required, any dependencies on other parameters, and examples. Example: 'filter' (string, optional, enum: [status_active, status_inactive, type_read, type_write], default=status_active) → 'Filter results by status or type. If omitted, returns only active resources.'
Document return types and structures for all tools. Specify which fields are always present vs. optional. For paginated tools, declare pagination fields (limit, offset, total_count, next_cursor). Example: 'Returns an object: { tools: [{name, description, risk_level, params_schema}], total: number, next_cursor: string|null }'
Implement confirmation/dry-run for irreversible operations. Add a 'dry_run' boolean parameter (default=false) to dexter_execute_asset_action and dexter_reconcile_asset_action. When true, return what WOULD happen without executing. When false and amount exceeds threshold, return result with type 'input_required' asking user to confirm.
No visible output schemas or documented return types. LLMs cannot plan downstream tool calls or extract the right data when they don't know what fields to expect.
Delegation to external services (@dexterai/x402-mcp-tools, @dexterai/vault) hides parameter contracts. Tool definitions appear to be inferred from package naming rather than explicitly registered with full schemas in the MCP server code.
No parameter descriptions visible. Every parameter needs description explaining what it controls (type, range, valid values, dependencies). Ambiguity like 'status' or 'type' params without context forces LLMs to guess.
Multi-step workflow tools (prepare → execute → reconcile) lack chaining guidance. Descriptions do not indicate that prepare_asset_action must be called before execute_asset_action, or what fields reconcile requires from execute.
Add error recovery guidance to descriptions. State what to do on common failures. Example: 'x402_check' → 'Check validity of x402 transaction. On error (invalid_signature, expired), call x402_fetch to retrieve transaction details and retry. If status=failed, the transaction cannot proceed.'
Clarify multi-step workflows in descriptions. Add dependency hints: 'dexter_prepare_asset_action' → 'Prepare an asset action (e.g. swap, stake, transfer). This tool returns a prepared_action_id. Pass this ID to dexter_execute_asset_action to actually execute. Always prepare before executing.'
Expose human-readable identifiers where applicable. If dexter_wallet tools accept wallet_address (string) in addition to internal wallet_id, document this. Users say 'my wallet', not 'w_1234567'. Provide search tools (search_wallets, search_channels) to help LLMs resolve names to IDs.
Return chainable IDs in responses. If dexter_execute_asset_action returns { action_id, tx_hash, gas_fee }, ensure that action_id is accepted by dexter_asset_action_status and dexter_reconcile_asset_action. This enables natural tool composition without extra lookups.
Add input validation and actionable error messages. On invalid asset amount (e.g. negative, exceeds balance), return '{error: "Invalid amount: -5. Must be positive and ≤ wallet_balance (100.5 tokens)."}' instead of a 500 error. Let LLMs self-correct.
Document rate limits and timeout behavior. If any x402_ tool has rate limits or slow external calls, state: 'May take 2-5 seconds due to blockchain confirmation. Timeout: 30s. Retryable on 'connection_timeout'. Not idempotent if called multiple times in quick succession without waiting.'
Review and remove secrets from tool parameters and responses. Ensure no private keys, tokens, session IDs, or API keys appear in parameter descriptions or return values. Use server-side secret injection via @dexterai/vault for credential handling.