credit_historyThe connected user's credit transactions (purchases, campaign spend, participation rewards), newest first. Free, read-only. Use to account for what this connector has spent or earned. Top-ups are NOT available in-connector — send the user to app.productclank.com/credits/purchase when the balance runs low.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20 | |
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately states read-only behavior, which matches the readOnlyhint annotation, and adds useful behavioral details beyond it: free, newest-first ordering, types of transactions included, and the fact that in-connector top-ups are unavailable. It does not contradict the annotations, but it also does not go deep into response shape or edge behaviors.
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?
Three short, purposeful sentences, each doing useful work: one states what the tool is, one states its intended use, and one gives the key out-of-band transaction steps. The description is front-loaded with the primary identity and does not waste words.
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?
Given the two self-describing optional params and the very helpful readOnlyhint annotation, the description covers the main things an agent needs: what data it affects, why to call it, and the external fallback to a purchase URL. It does not go into output shape, but because there is no output schema, listing transaction categories and order is reasonably complete for this simple history tool.
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 two params are optional limit and offset, whose names are fairly self-descriptive. The schema documents the limit default and bounds, leaving offset semantics implicit. The description's 'newest first' adds context for reading the list but does not explain pagination, so the description adds only marginal value beyond the schema.
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 clearly states that this returns the connected user's credit transactions (purchases, campaign spend, participation rewards), newest first. It is specific about the resource and ordering, and it is easy to tell apart from siblings like check_balance, though it does not explicitly name an alternative tool for the same purpose.
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 says to use it to account for spent or earned credits, which gives a clear intended use case. It also tells the caller that top-ups are not available in-connector, routing users to an external purchase URL when balance runs low. It does not explicitly address when check_balance should be used instead, but the usage guidance is still reasonably 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 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.