Publish everything in your basket, paying from your account balance. If the balance is short it does nothing and reports how much more is needed. Topping up the balance is done in the dashboard only.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses critical behavioral traits: 'If the balance is short it does nothing and reports how much more is needed'—an all-or-nothing behavior with a clear failure mode. It also states the top-up limitation, which is beyond basic expectations. No contradictions.
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 compact and front-loaded: the first sentence states the action, the second gives the failure behavior, and the third provides a key constraint. Every sentence earns its place; no fluff or repetition.
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 zero-parameter tool with no annotations and no output schema, the description covers the essential aspects: action, failure mode, and related constraint. It could mention what happens on success (e.g., confirmation), but given the simplicity, it's largely complete. Sibling tools provide additional context.
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 input schema has zero parameters, and the schema description coverage is 100% (empty). Baseline for zero parameters is 4. The description doesn't need to explain parameters since there are none; it focuses on behavior, which is appropriate.
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 the tool's function: 'Publish everything in your basket, paying from your account balance.' This is a specific verb+resource action that distinguishes it from siblings like 'get_basket' (retrieve) and 'order_backlink' (individual order).
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 usage context: it publishes everything and pays from balance. It also gives a key exclusion—'Topping up the balance is done in the dashboard only'—which implies when not to use this tool (if balance is short, you must go to dashboard). It doesn't explicitly mention alternatives like checking balance first, but the context is 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.
Each tool targets a distinct action or resource: balance, article prompt, basket contents, donor search, link status, order creation, and publishing. No two tools share the same purpose, making selection unambiguous.
All tool names follow a consistent verb_noun snake_case pattern (check_balance, get_article_prompt, list_donors, order_backlink). Verbs are appropriate to the action, and nouns clearly identify the target resource.
Seven tools is well-scoped for a backlink ordering service. Each tool addresses a distinct step in the workflow—search, order, review, publish, monitor—without redundancy or bloat.
The core lifecycle is covered: find donors, draft order, inspect basket, publish, and track links. The only notable gap is that basket items cannot be removed or edited before publishing, which can trap an agent that mis-orders.