Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server provides 20 blockchain query tools with consistently present descriptions and basic parameter schemas. Naming follows verb_noun convention (portal_get_*, portal_list_*, portal_evm_*, etc.). However, there are significant gaps: parameter schemas lack type definitions for most inputs, descriptions are generic and lack actionable guidance for LLM selection, output schemas are entirely undocumented, and error handling is absent from visible tool definitions. The tools are all READ_ONLY and well-scoped (no tools combining multiple responsibilities), but they fall short of production-grade quality. No pagination hints, no rate-limit guidance, no chaining documentation. Parameter descriptions are present but minimal (e.g., 'The blockchain network identifier' repeated 15+ times without elaboration of valid network values or discovery paths).
Input parameter schemas lack proper type definitions. Visible schemas show only string/number/array at top level with no nested object validation, min/max bounds, or regex patterns. E.g., 'network' parameter appears in 15+ tools but has no enum constraint listing valid networks; 'from_timestamp' and 'to_timestamp' appear across 8 tools with no format validation (ISO 8601 vs Unix timestamp ambiguous).
Add JSON Schema definitions for all input parameters: enum constraints for 'network' (list all valid network names), format/pattern for timestamps (e.g., 'ISO 8601 string: 2024-01-15T10:30:00Z'), and min/max bounds for numeric parameters like 'limit' (e.g., 'limit: 1-1000, default 20'). Reference portal_list_networks in network parameter descriptions.
Document output schemas for all 20 tools. Use a structured format (JSON Schema or TypeScript interface examples) showing expected response fields, types, and sample values. E.g., for portal_get_wallet_summary: {address, balances: [{token, amount, usdValue}], transactions: [{hash, from, to, value, timestamp}], holdingCount}
Enhance parameter descriptions by adding: valid values or discovery method, format/encoding, range/bounds, and any dependencies. Example: 'The blockchain network identifier. Use portal_list_networks to discover valid values. Case-sensitive. E.g., ethereum, polygon, solana'
Add pagination guidance to tools returning lists. Specify: is pagination supported? If so, describe limit parameter (range and default), offset/cursor mechanism, and total count or next_cursor in response. Cap results at 50-100 by default per arcade.dev/patterns/paginated-result.
Document error cases and recovery paths for each tool. E.g., for portal_resolve_entity: 'If entity not found, try portal_list_networks to confirm the network is valid, or search for similar entity names.' Reference pattern:recovery-guide.
Standardize timestamp parameters: use ISO 8601 string format throughout (YYYY-MM-DDTHH:MM:SSZ) and document this in every parameter description. Include examples: 'from_timestamp: ISO 8601 string, e.g., 2024-01-15T10:30:00Z'
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Output schemas are completely undocumented. No visible schema definitions for any tool's response. LLMs cannot know what fields to expect, cannot plan downstream tool calls, and cannot extract structured data reliably. E.g., does portal_get_wallet_summary return {balance, transactions, holdings} or {total, items, metadata, pagination}? This forces agents to guess and retry.
Parameter descriptions are generic placeholders lacking actionable LLM guidance. 'The blockchain network identifier' appears in 15+ tools with zero guidance on valid values, discovery, or constraints. No mention of case sensitivity, required format, or how to discover available networks (via portal_list_networks? hardcoded list?). Generic descriptions force LLMs to infer intent.
No pagination or result-limiting guidance. Eight tools return potentially large result sets (portal_get_recent_activity, portal_evm_query_transactions, portal_evm_query_logs, portal_get_time_series) but descriptions do not mention pagination, result caps, or next_cursor patterns. No documented limits for result counts. LLMs may request unbounded result sets that blow context windows.
No error handling or recovery guidance in visible tool definitions. No documentation of what happens when a network is invalid, an address does not exist, or a timestamp range is malformed. No guidance for LLMs on retryability, user-correctable vs. fatal errors, or recovery paths.
Timestamp parameters lack format specification. 'from_timestamp' and 'to_timestamp' appear in 8 tools with only description 'Start time for...' or 'End time for...'. No indication of format (ISO 8601 string vs. Unix timestamp vs. milliseconds). LLMs frequently miscalculate timestamp conversions, producing wrong dates.
No chaining documentation. E.g., portal_get_wallet_summary should document what fields it returns that downstream tools (like portal_evm_query_transactions) accept. No guidance on required ID dependencies. Agents cannot plan multi-step workflows without guessing.
Debug tools (portal_debug_evm_call, portal_debug_evm_query_traces) lack security context. No indication of who can call them, what permissions are required, or whether they expose sensitive debugging info. Tools prefixed 'debug' often bypass normal restrictions, should declare their risk and auth requirements.
Clarify tool selection by adding WHEN to call each tool in descriptions. E.g., 'Call this when you need recent on-chain activity. For wallet holdings, use portal_get_wallet_summary instead. For historical data across weeks/months, use portal_get_time_series.'
For debug tools, add explicit security/permission notes in descriptions. E.g., 'ADVANCED: Requires debug:execute scope. Exposes execution traces; use only for authorized analysis.' Reference pattern:scope-declaration.
Document how tools chain together. E.g., in portal_resolve_entity description: 'Returns entity_id and metadata fields that can be passed to portal_get_recent_activity (use entity_id as address parameter).'
Add rate-limit and timeout guidance. E.g., 'Large time ranges (>90 days) may timeout. If so, split into smaller windows and merge results. Requests are rate-limited to 100 per minute per API key.'
For portal_list_networks and portal_evm_query_logs, document the full structure of returned enum/array values. E.g., portal_list_networks should state: 'Returns array of network objects: {id, name, type (evm|solana|bitcoin|substrate), rpcUrl, explorerUrl}'
Add example values or links to documentation in tool descriptions (not parameter descriptions). E.g., 'Resolves blockchain entities to normalized form. Learn more: docs.sqd.io/portal/entities'
Specify idempotency guarantees for read-only tools (they are all idempotent, which is good, make this explicit in MCP tool annotation via idempotentHint: true)