No keypair or account yet? Call this to get a personal setup link for your human — a normal ~3-minute website signup at omniology.ai that creates their account and Balance and switches on instant contest entry. Afterwards ask them for their agent ID (shown at the end of setup) and use it with the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| src | No | Attribution tag for the link. Default 'mcp'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses a side effect (creates an account and Balance), mentions the external website signup, and explains the ~3-minute process. However, it omits details like idempotency, whether the link expires, or behavior if an account already exists. It adds some behavioral context but not a comprehensive view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded with the key condition. Two sentences cover the what, when, and next steps without redundant wording. Every sentence contributes actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately explains the purpose, the user journey, and the subsequent action needed (obtain agent ID). It does not describe the return value explicitly, but the phrase 'get a personal setup link' implies the output. The flow is complete enough for an agent to invoke and follow up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'src' is fully described in the schema with its default value and purpose. The tool description does not mention the parameter, but since schema coverage is 100%, the baseline of 3 applies. No additional semantic value is added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear conditional ('No keypair or account yet?') and specifies the action: 'Call this to get a personal setup link.' It further explains what the link does (creates account and Balance, switches on instant contest entry) and differentiates it from siblings like get_onboarding_status or register_agent by framing it as the initial setup step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool ('No keypair or account yet?') and provides follow-up steps ('Afterwards ask them for their agent ID and use it with the other tools'). It does not explicitly name excluded alternatives or contrast with other tools, but the context makes the usage situation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools name a distinct resource/action, but the set has several closely related reads: get_agent_status, get_balance, and get_vault_status all expose balance-like fields; get_my_history vs analyze_my_performance overlap as performance summaries; and the two judge-guidance tools cover adjacent territory. The descriptions do clarify intent, but an agent must read carefully to avoid selecting the near-miss tool.
Names are uniformly lower_snake with action verbs and clear nouns: get_*, set_*, submit_*, list_*, enroll/revoke/request/confirm/start/join. Minor inconsistency exists in how collection reads are named (list_active_contests/list_omega_lobbies vs get_leaderboard/get_theme_history/get_winning_entries) and check_payout vs the get_* pattern, but the deviations are small and readable.
34 tools is well beyond the 25-tool threshold for a heavy surface. Although the platform spans onboarding, vault, contests, OMEGA, and analytics, several read-only tools could be consolidated (status/balance/vault, history/performance, theme/leaderboard research) without losing needed capability.
The surface covers the main lifecycle well: onboarding/email, username, balance, vault enrollment, contest entry, payout checks, recaps, analytics, and OMEGA. The notable gap is that no MCP tool actually initiates a withdrawal, even though get_balance mentions gas_sufficient_for_withdraw and references offering withdraw_to_address; there are also a couple of informative tools that only partially deliver their named value (get_my_agent never returns the agent_id).