Loading ToolBench
Trade K-pop artist lightstick tokens on the K-Trendz bonding curve market with Paymaster gas sponsorship
This MCP server exhibits severe definition quality issues across all dimensions. While tool names follow a verb-noun pattern (approve-agent, get-users, etc.), the implementation lacks proper MCP protocol structure, schema documentation, and error handling. The server appears to be a Supabase Edge Functions deployment with admin-only operations, but no evidence of actual MCP tool registration, protocol handlers, or structured input/output schemas. The source code shows only Vite+React frontend configuration and function entry points, no MCP server implementation, message handlers, or tool definition exports. Schemas are inferred from the evaluation brief but not visible in the provided source. Descriptions are present but generic and do not follow LLM-optimized patterns. Most critically, there is no evidence this is an MCP server at all, it appears to be a web application with backend functions, not a Model Context Protocol implementation.
Admin endpoint to approve, reject, or suspend pending agents with optional paymaster approval and trading limits
Admin endpoint to list all users or run bot detection analysis with lightstick holdings
Admin endpoint to reset a user's password
Admin endpoint to sell K-pop lightstick tokens on behalf of a user with paymaster-sponsored gas
Admin endpoint to transfer K-pop lightstick tokens between wallets with paymaster-sponsored gas
Admin endpoint to manually adjust a user's USDC balance with audit logging
Admin endpoint to add or remove user roles (admin, moderator, user)
No visible MCP tool registration or protocol handler code. Tools are inferred from brief; actual tool definitions not found in source.
Input schemas not documented or visible in source code. Schemas inferred from brief only.
Tool descriptions are generic and do not follow LLM-optimized patterns. Missing 'WHAT', 'WHEN', and 'WHY' context. Examples: 'Admin endpoint to...' does not explain when an LLM should use this vs. related tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2026-07-28+ | v2 |
Parameter descriptions are minimal. Examples: 'The ID of the agent to approve' lacks format, constraints, or examples. 'The new password (minimum 6 characters)' does not explain validation rules or what happens on validation failure.
No error handling guidance. Tools marked as WRITE or IRREVERSIBLE but no documentation of failure modes, recovery steps, or whether operations are idempotent. 'sell-fanz-token' and 'transfer-fanz-token' are destructive but lack dry-run or confirmation pattern.
No output schema documented. Tools return opaque responses; LLMs cannot determine what fields to expect or how to chain results to downstream tools.
Credentials and secrets appear unprotected. 'KTRENDZ_API_KEY' in requiredEnv suggests API key injection, but no evidence of server-side secret handling. Tool parameters may expose tokens or session data.
No permission gates or scope declarations visible. All tools are labeled as admin endpoints but no evidence of role/permission checks before execution. Missing permission-gate pattern.
No audit logging visible. Admin operations like reset-password, sell-fanz-token, and update-usdc-balance require full audit trails (who, what, when, parameters, outcome) for compliance and incident response. None visible in source.
Semantic naming issue: 'approve-agent' uses hyphens; 'daily_limit_usd' uses underscores. Inconsistent casing (approve-agent vs approve_agent) will confuse LLM parsing and tool lookup.