Aptos Network Intelligence for AI Agents. APT price, network stats, Move module verification, DeFi protocol TVL, stablecoin checks, wallet intelligence, yield opportunities, RWA on Aptos. Evidence-grade data for Move-based institutional DeFi.
AptosOracle provides 6 read-only tools with reasonable descriptions (avg 150 chars) and basic input schemas. All tools have descriptions and most parameters are typed. However, schemas lack formal JSON Schema structure (no explicit 'type', 'required', 'properties' blocks visible in registration), parameter descriptions are minimal or absent, and output schemas are not documented. Error handling is present but generic. No tool annotations (readOnlyHint, etc.). Naming is clear and verb-based (overview, account_info, module_check, protocol_tvl, stablecoin_check, defi_yields), following verb_noun convention. Composition is sound, each tool has one responsibility. Missing: structured output documentation, comprehensive parameter validation guidance, and recovery hints in error messages.
Get Aptos account information: APT balance, sequence number, authentication key, token types held, and risk score.
Get DeFi yield opportunities on Aptos. Returns pools with APY, TVL, impermanent loss risk. Filters by minimum TVL (default 100k USD) and limit (max 50).
Verify Move modules deployed at an Aptos address. Returns module count, exposed functions, structs, and friends. Move modules are on-chain verified by default.
Get Aptos chain overview: APT price (USD/EUR), 24h change, market cap, volume, network stats (chain ID, ledger version, block height, epoch), and total TVL.
Get DeFi protocol TVL on Aptos. If no protocol specified, returns top 20 Aptos protocols by TVL. If protocol specified, returns detailed TVL, category, chains, and 1d/7d changes.
Check stablecoin peg status on Aptos. Supports USDC, USDT, WBTC. Returns price, peg deviation, peg status (STABLE/MINOR_DEVIATION/DEPEGGED), risk score, and Aptos Move contract address.
Input schemas lack formal JSON Schema structure. Parameters are documented in descriptions but not registered with explicit 'type', 'required', 'properties', 'minValue', 'maxValue' constraints. LLMs cannot validate inputs against machine-readable constraints.
Output schemas are not documented. Tool descriptions state what is returned (e.g., 'Returns module count, exposed functions, structs, and friends') but the actual response structure (field names, types, nesting) is not formally specified. LLMs cannot plan downstream tool calls without knowing response fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Parameter descriptions are minimal or absent. 'address' parameter in account_info and module_check has description 'Aptos account address (0x...)' but lacks guidance on format validation, length, or error handling. 'protocol' in protocol_tvl lacks description entirely in the schema definition.
Error responses are generic. When account_info fails with 'Account not found: {address}', there is no recovery guidance (e.g., 'Try search_accounts() with a partial address'). Errors do not categorize as retryable vs. fatal.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata. All 6 tools are read-only but this is not formally declared in the tool definition, forcing LLMs to infer safety from descriptions.