GoPlus MCP exhibits significant quality gaps across all 7 tools. While tool names follow verb_noun conventions and descriptions exist, they are generic, lack actionable guidance, and parameter documentation is minimal. Input schemas are present but incomplete, many parameters lack type constraints and validation guidance. Output schemas are undocumented entirely, preventing agents from understanding response structure. Error handling is absent, leaving no recovery path for agents. The codebase uses generic API call patterns without per-tool customization or inline safety validation. Against the production baseline of 194 chars avg description length and 100% param documentation, this server delivers ~120 chars of generic text and 50% param coverage.
Output schemas completely undocumented. No tool specifies what fields are returned, their types, or how downstream tools should chain results. Agents cannot plan multi-step flows or extract required IDs.
Descriptions are generic and lack actionable guidance. Examples: 'Analyze token contracts for security risks' (45 chars) does not explain WHEN to use this vs malicious_address, WHAT risks it detects, or WHAT OUTPUT it returns. Production baseline is 194 chars with WHAT/WHEN/OUTPUT clarity.
Rewrite ALL tool descriptions following the 50-200 character production baseline. Template: '[VERB] [RESOURCE] to [ACTION]. Use this when [CONDITION], not [SIMILAR_TOOL]. Returns [KEY_FIELDS].' Example: 'Analyze a token contract for security risks (scams, rug pulls, honeypots). Use this to verify a contract before trading, not to check an address reputation. Returns risk_level (high|medium|low), risks (array of risk_id), suspicious_indicators.'
Convert chain_id text enums to proper JSON Schema constraint. In tool registration, change chain_id from type:string to an enum array: ['1', '56', '137', ...]. Add description: 'Blockchain network ID (e.g., 1=Ethereum, 56=BSC, 137=Polygon). See supported chains list.'
Add input validation and error recovery. Wrap API calls in try-catch. Return structured errors: '{error: "invalid_chain_id", received: "9999", valid_chains: [1, 56, 137, ...], retry: true}'. This tells agents to self-correct without a lookup call.
Document output schemas for all 7 tools. Specify response structure as JSON Schema. Example for token_security: '{risk_level: enum[high|medium|low], risks: [{id: string, name: string, severity: enum}], contract_verified: boolean}'. This enables agents to chain tools and extract IDs for follow-up calls.
Add per-tool safety descriptions for contract_addresses and addresses parameters. Specify: max count (e.g., 1-50 per call), format validation (EVM: 0x + 40 hex chars, Solana: base58 32-byte), and what happens on invalid input. Example: 'One or more contract addresses (EVM: 0x + 40 hex; max 10 per call). Invalid addresses are skipped; empty input returns error.'
Score history
Overall score trend
↑ 2 points across a rubric change (v1 → v2)
41/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
41
2026-07-28+
v2
2026-03-09
F
39
-
v1
Analyze token contracts for security risks and identify potential scams
Parameters lack validation constraints and guidance. chain_id accepts a free-form string enumeration in the description (40+ chain IDs listed as text) instead of a proper JSON Schema enum. LLMs cannot reliably parse text enums and will hallucinate invalid chain IDs. contract_addresses parameter accepts comma-separated strings with no validation rules, format constraints, or guidance on how many addresses are safe to submit.
No error handling or recovery guidance. Tools make external API calls (via axios in api.js) but source shows no try-catch, validation, or error messages that would tell an agent what to do on failure. A failed API call returns a raw error with no recovery path.
No parameter descriptions for token_id in nft_security ('Optional token ID for specific NFT analysis' is 42 chars and does not explain format, when it's required vs optional, or what happens if omitted). Agents cannot determine whether to include it.
No pagination, limits, or result structuring documented. Agents calling token_security with 100 contract addresses have no idea if the tool will return 100 results, batch them, or fail. No limit enforcement, no pagination tokens, no guidance on batch size.
Implement batch result handling. If multiple addresses are analyzed, return per-item status: {results: [{address: '0x...', risk_level: 'high', risks: [...]}, {address: '0x...', error: 'invalid_format', valid_format: '0x + 40 hex'}]}. This lets agents know which items succeeded and which failed without retrying everything.
Add rate limit and timeout guidance. Document: 'This tool calls the GoPlus API. Rate limit: 100 calls/min. Timeout: 10 seconds. On timeout, wait 5 seconds and retry.' This prevents agent retry loops from overwhelming the backend.
Parameterize chain selection for tools that assume EVM. solana_token_security and sui_token_security should clarify 'Solana blockchain only' and 'Sui blockchain only' in descriptions, not require agents to infer from the tool name.
Add optional 'include_indicators' or 'detail_level' parameter to token_security. Let agents request either summary (risk_level only) or detailed (full risk array with indicators). This reduces token bloat for simple checks.
Document the API key requirement and failure path. If API credentials (GOPLUS_API_KEY, GOPLUS_API_SECRET) are missing, tools currently fail silently. Add to server startup: 'GoPlus API credentials required. Set --key and --secret flags. On credential failure, all tools return: {error: "auth_failed", hint: "provide --key and --secret"}'