Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
NEARWEEK MCP server provides 10 blockchain query tools with consistent naming conventions and reasonable schema documentation. All tools follow verb_noun naming patterns (near.getAccount, near.viewFunction, etc.) and have descriptive schemas. However, descriptions vary in quality, some are well-detailed (near.viewFunction), while others are terse (near.getBlock). Output schemas are not explicitly documented; only input schemas are visible. Error handling lacks recovery guidance. No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. Parameters are well-typed with enums for finality levels, but lack granular constraints (e.g., no min/max for numeric indices). Composition is good, tools chain well (e.g., getTransaction + viewFunction), though some parameter repetition (block_id, height, finality) across tools suggests potential for abstraction.
Tools (10)
near.getAccessKeyread onlysource verified80/100
Get details of a specific access key for a NEAR account
near.getAccessKeysread onlysource verified80/100
Get all access keys for a NEAR account
near.getAccountread onlysource verified82/100
Get NEAR account details including balance, storage, and code hash
near.rpc tool lacks specificity. Generic 'method' and 'params' parameters with minimal documentation invite LLM hallucination of invalid RPC method names. Description does not guide when to use near.rpc vs specific domain tools (near.getAccount, near.viewFunction).
Output schemas are not documented for any tool. LLMs cannot infer which fields will be returned, making it impossible to plan downstream tool calls or extract required data. Example: near.getAccount returns 'amount', 'locked', 'code_hash', 'storage_paid_at', these should be documented in the tool definition.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint) despite all tools being read-only and idempotent. MCP spec 2026-07-28 rewards tool annotations; their absence reduces spec alignment score.
Recommendations
Document output schemas for all tools. Example for near.getAccount: 'Returns: {amount: string (yoctoNEAR), locked: string, code_hash: string, storage_paid_at: string, block_height: number, block_hash: string}'. This enables the LLM to plan downstream calls and extract required fields.
Add tool annotations to all tools. All 10 tools are read-only and idempotent, add 'readOnlyHint': true and 'idempotentHint': true to each tool definition in the MCP ToolDefinition. This improves protocol alignment and helps agents optimize execution.
Enhance near.rpc description and constraints. Replace generic 'method' and 'params' with guidance: 'method' should reference valid NEAR RPC method names (e.g., query, tx/send_tx, block, chunk); 'params' should document structure per method. Add a note: 'For specific blockchain queries, prefer domain-specific tools (near.getAccount, near.viewFunction, etc.) which provide better error handling and documented output.'
Add parameter constraints. For all numeric parameters (height, shard_id), specify valid ranges. Example: 'height: number (must be > 0, typically >= current block height - 120). For block_id, specify format: 'block_id: string (64-character hexadecimal hash, e.g., "abc123...")'.
Document parameter relationships and precedence. Example for near.getBlock: 'Specify one of: block_id (hash), height, or finality. If multiple provided, precedence: block_id > height > finality. If none provided, defaults to finality=near-final.'
Add recovery guidance to tool descriptions. Example: 'If the account is not found, try near.getAccountChanges to verify it existed in a recent block. If a contract method fails, call near.getAccount to confirm the contract exists and is deployed.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 63 points across a rubric change (v1 → v2)
63/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
C
63
<=2025-11-25
v2
2026-03-09
F
0
-
v1
read onlysource verified80/100
Get NEAR transaction status with execution receipts
near.rpcread onlysource verified50/100
Make a generic NEAR RPC call with custom method and parameters
near.viewFunctionread onlysource verified83/100
Call a read-only view method on a NEAR smart contract
Error handling is minimal. No error descriptions visible in tool definitions; no recovery guidance provided. Example: If near.viewFunction receives an invalid contract_id, what error is returned? Can the LLM retry? Should it call near.getAccount first to validate the contract exists?
Parameter descriptions lack actionable constraints. 'finality' enum is documented, but 'height', 'block_id' lack clarification on mutual exclusivity and precedence. 'block_id' should document format (e.g., '64-char hex hash'); 'height' should specify valid range.
near.rpc 'params' field has no type constraint. Current schema: 'params': {'description': 'Method parameters (object or array, depending on the method)'}. This is too vague; LLMs cannot validate inputs. Schema should use 'oneOf' or 'anyOf' to constrain valid param structures, or provide a reference to NEAR RPC docs.
Descriptions omit use-case guidance. Which tool should I call to monitor account balance over time? Should I loop near.getAccount with different finality levels? No tool explains common patterns or when to prefer one over another (e.g., 'Use near-final for near-real-time data; use final for confirmed state.').
near.getBlocknear.getBlockChangesnear.getChunk
Improve near.rpc discovery. Return documentation links or enumerate available RPC methods in the description. Example: 'See https://docs.near.org/api/rpc/introduction for full RPC method reference. Common methods: query (read-only state), tx (transaction status), block, chunk, validators.'
Add batch variants where applicable. If an agent often calls near.getAccessKeys for multiple accounts, offer near.getAccessKeysForMultiple(account_ids: string[]). Batch calls reduce latency and token overhead.
Clarify finality semantics. Document in tool descriptions what optimistic, near-final, and final mean in terms of block confirmation time and risk of rollback. Example: 'optimistic: included in mempool (~1s latency, subject to rollback); near-final: 2+ validators confirmed (~2s, <0.1% rollback risk); final: irreversible (~3s, used for settlement).'
Add input validation error examples to tool docstrings. Example: 'Invalid finality: must be one of: optimistic, near-final, final. Got: "confirmed". Did you mean near-final?'