get_earningsThe connected user's participation totals: points, credit balance, and reply stats (submitted / approved / rejected / strikes) for work submitted through this connector. Free, read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description adds 'Free' and explicitly repeats 'read-only' with the phrase 'Free, read-only.' It also clarifies scope (connected user, work submitted via this connector) and the exact data categories returned. No contradiction with annotations.
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?
A single, well-structured sentence is front-loaded with the main deliverable ('participation totals') followed by a compact list of the exact data elements. Every phrase earns its place — no filler, no repetition of the title beyond the core verb.
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?
The tool is a simple 0-parameter read-only operation with no output schema. The description fully covers purpose, scope, return contents, cost, and safety. Nothing an agent needs to decide when to call it and what it will receive is missing.
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 tool has zero parameters and the schema coverage is 100% with no required fields, so the description carries no burden on parameter semantics. The baseline of 4 applies because no parameters need clarification.
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 uses a clear verb-plus-resource pattern: it returns 'the connected user's participation totals' and enumerates exactly what's included (points, credit balance, reply stats with statuses). It also scopes the data to 'work submitted through this connector,' which distinguishes it from sibling tools like check_balance or credit_history.
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 provides clear context for when to use the tool: when you need the connected user's participation totals and reply stats. It doesn't explicitly name alternatives or state exclusions, but the specificity of 'participation... submitted through this connector' implies the intended use case well enough.
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 map cleanly to a distinct resource and action: campaigns, posts, products, research, content spaces, and submissions. A few pairs are close—`create_campaign` vs `create_content_campaign` and `check_balance` vs `get_earnings`—but the detailed descriptions make the intended selection clear.
The set largely follows a consistent `verb_noun` snake_case pattern (`list_campaigns`, `generate_posts`, `update_campaign`, `submit_participation`). Minor deviations keep it from a perfect score: `credit_history` lacks a verb, and `create_campaign` reads as generic next to the more specific `create_content_campaign`.
30 tools is high and makes the server feel heavy, but the domain genuinely spans products, credits, campaigns, research, post discovery, content spaces, boosts, and participation rewards. The breadth mostly earns the count, though it sits on the wrong side of the typical 3–15 range.
The core end-to-end workflow is covered: create and configure campaigns, discover and refine posts, run research, find opportunities, submit work, and measure results. Gaps exist but are minor for the central purpose—product listings can’t be updated or deleted, and delegates can be added but not removed.