Let AI agents buy dofollow backlinks: search 50,000+ vetted sites, order, publish. 7 hosted tools.
Scored across 10 tools
Each tool targets a distinct action and resource: balance, basket, donors, invoices, links, publishing, and article prompt editing. Even similar tools like issue_proforma and send_invoice are clearly separated by creation versus emailing an existing document.
All tool names follow the same lowercase verb_noun pattern, with predictable verbs like list_, get_, order_, and publish_. The naming convention is consistent throughout the set.
With 10 tools, the server is well-scoped for a backlink purchasing and account management workflow. Each tool covers a necessary step in the user journey without unnecessary duplication.
The core lifecycle is well covered: discover donors, order backlinks, inspect basket, publish, monitor links, and handle invoices. The main gap is the lack of a remove-from-basket or cancel/update tool, which is a minor but real drawback.
Get the Rixot account balance (USD).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states that it retrieves a balance, without mentioning side effects, permission requirements, rate limits, or return format. This is minimal but not misleading.
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 a single, concise sentence that is immediately understandable. No unnecessary words 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 read operation with no output schema or annotations, the description covers the essential information: what is retrieved and in what currency. It is sufficiently complete for the tool's simplicity.
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 is empty, so the baseline is 4. The description adds the currency (USD), which provides useful context even though there are no parameters to document.
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?
Clearly states the action ('Get') and the resource ('Rixot account balance'), with the USD denomination adding specificity. This distinguishes it from sibling tools, which focus on articles, baskets, donors, links, and backlink ordering.
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?
No guidance on when to use this tool versus alternatives. While siblings are topically unrelated, the description provides no explicit context or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return our default article-generation prompt so you can see exactly how the article is written and, optionally, edit it. Pass the edited guidance back as "recommendations" in order_backlink. The output contract (JSON title/html/url, one dofollow link, no images) is fixed so the article can be published.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | ||
| language | No | ||
| target_url | No | ||
| recommendations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool returns the prompt, that editing is optional, and that the output contract is fixed. It also clarifies that the edited guidance is passed via order_backlink, not directly saved here, implying a read-only nature. However, it does not explicitly state safety or side effects, which would be ideal.
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 two sentences, front-loaded with the primary action, and provides essential context about editing and output constraints. Every sentence adds value without unnecessary fluff.
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 description covers the main purpose and workflow, and mentions the fixed output contract, which is important. However, it omits any explanation of how parameters like keyword, language, and target_url affect the prompt, and the role of the recommendations parameter for this tool is ambiguous. Given 4 optional params and no output schema, more detail is needed for full completeness.
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 schema has 4 parameters (keyword, language, target_url, recommendations) with 0% description coverage. The description only mentions 'recommendations' but in the context of order_backlink, not this tool's own parameter. It fails to explain keyword, language, or target_url, leaving their meaning and usage unclear. This is a significant gap given the lack of schema descriptions.
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 'Return our default article-generation prompt', which is a specific verb ('return') and resource ('default article-generation prompt'). It also explains the purpose (see how the article is written) and distinguishes from sibling tools like order_backlink by showing the workflow of editing and passing recommendations.
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 explicitly says to 'Pass the edited guidance back as "recommendations" in order_backlink', which guides when and how to use this tool in conjunction with another. It implies using this tool before ordering to review/customize the prompt. However, it does not explicitly state when not to use it or name alternative tools beyond the contextual flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what is currently in your basket (inspect the drafted articles/placements before publishing).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'List' clearly indicates a read-only operation, and the parenthetical adds context about inspecting drafted content. It doesn't disclose return format or pagination, but for a simple list operation, the description sufficiently conveys non-mutating behavior.
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 a single, front-loaded sentence. The main action ('List what is currently in your basket') is stated first, followed by a parenthetical clarification. No wasted 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?
For a simple tool with no parameters and no output schema, the description covers the main aspects: what it does and when to use it. It doesn't specify return values, but the verb 'List' implies the output is the basket contents, which is sufficient for this simple 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 tool has zero parameters, so the schema provides all needed info. The description adds meaning by explaining the purpose (basket inspection), which complements the empty parameter schema. Baseline for 0 params is 4.
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 specific verb ('List') and resource ('your basket'), and clarifies the scope as 'drafted articles/placements before publishing.' This clearly distinguishes it from sibling tools like publish_basket or order_backlink.
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 phrase 'before publishing' gives clear usage context: use this to inspect the basket prior to publishing. It implicitly differentiates from publish_basket, though it doesn't explicitly name alternative tools or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a proforma invoice for an UPCOMING balance top-up of the given USD amount (1–100000) and email it (default) to the invoice email, or to "to". Returns the number, due date and PDF link. Charges nothing — the proforma is paid by topping up at rixot.com/add-funds, after which the paid invoice appears automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional recipient; default is the invoice email or the account email. | |
| No | Email the proforma right away (default true). | ||
| amount | Yes | USD amount of the planned top-up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool emails by default (controllable via the 'email' boolean), returns a number/due date/PDF link, and charges nothing, with the paid invoice appearing automatically after top-up. It does not cover error conditions or idempotency, but given the simplicity, it discloses the key behaviors well.
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 a single, dense sentence that front-loads the core action and then packs in defaults, return values, and payment flow with no wasted words. Every clause adds necessary information, making it appropriately concise and well-structured.
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 tool's simplicity, the description covers everything an agent needs: the action, parameters (amount, to, email) with defaults, return values (since there's no output schema), and the payment/posting behavior. There are no obvious gaps that would prevent a correct invocation.
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 schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by specifying the amount range (1–100000) not in the schema, clarifying the 'to' default (invoice email or account email), and confirming the 'email' default is true. This goes beyond the schema without redundancy.
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 opens with a specific verb and resource ('Issue a proforma invoice') and immediately scopes it to an 'UPCOMING balance top-up' with an amount range (1–100000). It also names the return values (number, due date, PDF link) and clarifies it charges nothing, making its function unambiguous and clearly distinct from sibling tools like send_invoice or list_invoices.
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's for creating a proforma for a planned top-up, with a default email behavior and an optional 'to' recipient. It explains that payment happens separately at rixot.com/add-funds, which implies when to use it (before payment). However, it does not explicitly name alternatives or state when NOT to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find marketplace donor sites for a niche/budget. Filters: domain_filter (substring), dr_min (Domain Rating >=), price_max / price_min (USD per link), page (20 per page).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| dr_min | No | ||
| price_max | No | ||
| price_min | No | ||
| domain_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses pagination (20 per page) and filter semantics, but doesn't explicitly state read-only nature, response format, or any side effects. For a simple list operation, this is adequate but not comprehensive.
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 a single concise sentence with a clear front-loaded purpose, followed by a compact list of filters. No wasted words, and structure effectively communicates the tool's behavior.
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?
While the description covers all parameters and pagination, it omits details about default behavior, sorting, or the structure of returned donor sites. Given the lack of an output schema, these omissions leave some ambiguity for an agent.
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?
With 0% schema coverage, the description compensates well by explaining each parameter: domain_filter as substring, dr_min as Domain Rating threshold, price_max/min as USD per link, and page as pagination. This adds meaningful context beyond the bare 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 the verb 'Find' and the resource 'marketplace donor sites' with a specific purpose (niche/budget). It distinguishes from sibling tools like list_links and list_invoices by naming a distinct resource, though it doesn't explicitly contrast with them.
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 implies usage for discovering donor sites based on filters, but provides no explicit guidance on when to use this tool versus alternatives like list_links or list_invoices, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's billing documents: paid invoices (one per completed balance top-up, numbers RX-…) and proforma invoices for upcoming top-ups (PF-…), each with amount, status and a PDF link. Company name, address, VAT and the invoice email are edited at rixot.com/billing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It conveys that the operation is a read-only listing through the verb 'List,' and it discloses what each entry contains (amount, status, PDF link). It also usefully points to where billing settings are edited, adding practical context beyond a bare list command.
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 two focused sentences with no fluff. The primary purpose and output details are front-loaded in the first sentence, and the second sentence adds a relevant operational note about billing settings. Every sentence earns its place.
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 no output schema, the description adequately explains what the agent will receive: invoice type, amount, status, and PDF link. It also covers the distinction between paid and proforma invoices, which is sufficient for a parameterless list 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 tool takes zero parameters stellarly, so there is no parameter semantics burden on the description. The baseline for 0-parameter tools is 4, and the description gives all necessary context without needing to explain input fields.
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 specific verb and resource: 'List the account's billing documents.' It clearly distinguishes between paid invoices (RX-…) and proforma invoices (PF-…), which helps an agent separate this from sibling tools like issue_proforma and send_invoice.
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 establishes clear context: this tool lists existing billing documents and includes both invoice types. It does not explicitly name alternative tools or when-not-to-use cases, but the listing behavior is distinct enough from issuing or sending invoices that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your ordered backlinks with status and published URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'List' clearly implies a read-only operation, and it discloses what content is included (status and published URL). However, it does not mention any authentication needs, response formatting, or other behavioral details, leaving some ambiguity.
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 a single concise sentence with no redundant words. It efficiently conveys the purpose and key output details.
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 simple list tool with no parameters and no output schema, the description adequately covers the core purpose. It could mention pagination or sorting, but these are not essential given the tool's simplicity. Missing details are minor.
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, making schema coverage trivially 100%. The description does not need to explain parameters, and the baseline for 0 params is 4, which is appropriate here since no additional parameter detail is required.
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 the specific verb 'List' with a clear resource ('ordered backlinks') and states the returned fields ('status and published URL'). It distinguishes itself from sibling tools like order_backlink and publish_basket by focusing on listing ordered backlinks.
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?
No guidance is provided on when to use this tool versus alternatives. The description merely states what it does without mentioning exclusions or context where another sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add backlink order(s) to your basket (no charge yet). Pick ONE content mode: (auto) send donor_ids + target_url + keyword and we write the article; (prompt) also send "recommendations" to steer the AI writer — fetch the editable base prompt with get_article_prompt first; (own) send target_url + "content" (+ optional "title","article_url") to publish your own ready HTML (requires own-content enabled). Then call publish_basket to pay from balance.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Own mode: article title. | |
| content | No | Own mode: your ready HTML article body. Requires own-content enabled on the account. | |
| keyword | No | Anchor keyword. Required unless sending own content. | |
| language | No | Article language, e.g. en. Default en. | |
| donor_ids | Yes | Donor site IDs from list_donors. | |
| target_url | No | The page the backlink points to (your site). REQUIRED in every mode, including own content. | |
| article_url | No | Own mode: preferred slug/URL for the article. | |
| recommendations | No | Prompt mode: your guidance for the AI writer (tone, angle, must-mention points). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses the non-charging behavior upfront ('no charge yet'), modal prerequisites ('requires own-content enabled'), and the required presence of target_url in every mode. It doesn't detail response formats or reversibility, but the key behavioral traits are covered.
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 sentences pack a lot of information without excess. The purpose is front-loaded, and the mode breakdown is structured with clear punctuation. The density is high but justifiable given the tool's complexity.
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 8 parameters, 3 modes, no annotations, and no output schema, the description covers the required parameter groupings, prerequisites, and downstream actions. It doesn't mention return values or error handling, but those are largely covered by the output schema absence and the schema descriptions.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining which parameter combinations are valid per mode: auto (donor_ids+target_url+keyword), prompt (+recommendations), own (target_url+content+optional title/article_url). This combinatorial logic is not present in 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 opens with a specific verb+resource: 'Add backlink order(s) to your basket (no charge yet)'. It clearly distinguishes from sibling tools by explaining it stages orders, while publish_basket handles payment. The three modes (auto, prompt, own) further specify scope.
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 when-to-use guidance per mode and references sibling tools: 'fetch the editable base prompt with get_article_prompt first' and 'Then call publish_basket to pay from balance.' It doesn't explicitly state when not to use the tool, but the mode selection and references to siblings give adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 parameters | |||
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.
Email an existing invoice or proforma (exact number from list_invoices, e.g. RX-2026-000123 or PF-2026-000007) with its PDF link — to the invoice email, or to "to".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional recipient email (e.g. your accountant). | |
| number | Yes | Invoice number from list_invoices. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does disclose the primary side effect: an email with a PDF link is sent to a recipient. However, the recipient logic is ambiguous — 'to the invoice email, or to "to"' does not clarify whether the `to` parameter supplements or replaces the invoice email, and there is no mention of failure behavior when the invoice has no email on file. The core action is transparent, but edge-case behavior is left to inference.
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 entire description is one dense sentence that front-loads the action and resource before the formatting hint and recipient clauses. There is no filler — every phrase either names the action, establishes the input contract, or clarifies the destination. The only minor blemish is the triple-use of 'to', which is compact rather than verbose.
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 simple 2-parameter, 1-required-parameter tool with no output schema, the description plus schema covers the essential call calibration: valid number format is exemplified, the recipient parameter is explained, and the source of valid numbers is identified. Remaining gaps — what happens if the invoice lacks an email address, and whether both recipients receive the message — are real but minor for such a small surface.
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?
Schema coverage is 100%, so the baseline is 3, but the description adds genuinely useful value: it reveals the exact number syntax (RX- prefix for invoices, PF- for proformas) that the raw schema descriptions ('Invoice number from list_invoices') do not provide. This example-based format guidance materially reduces the chance of an invalid call.
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 verb 'Email' with the resource 'existing invoice or proforma' states precisely what the tool does, and the concrete number examples (RX-2026-000123, PF-2026-000007) pin down the accepted input. The word 'existing' implicitly contrasts with sibling issue_proforma, and the reference to list_invoices distinguishes the sourcing flow. The recipient clause 'or to "to"' is slightly awkward but decipherable and does not obscure the core action.
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 instruction to use an 'exact number from list_invoices' gives the agent a clear sequencing guideline: look up the number first, then call this tool. 'Existing' also implies the precondition that the invoice/proforma must already be issued rather than created. However, it does not explicitly name an alternative (e.g., issue_proforma for creation) or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_donors1 field changedInput schema / properties / price_minAdded value: +{
+ "type": "number"
+}issue_proformalist_invoicessend_invoicecheck_balanceget_article_promptget_basketlist_donorslist_linksorder_backlinkpublish_basketSEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
SEO data for AI agents: Google SERP, keyword research, backlinks, site audits, AI answer visibility.
Buy SEO link placements across every marketplace: verified domains, held prices, one invoice.
SEO tools for AI agents: audits, Core Web Vitals, keywords, AI visibility, traffic, backlinks.
Add one secure layer between your agents and this server.
