Nautilinks Backlinks

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns explanatory content about the network, purchase flow, pricing, and authentication. It is consistent with the readOnlyHint and idempotentHint annotations, and adds valuable detail about the tool's output without contradicting the 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?

The description is concise, with two sentences that front-load the usage guidance and then list key topics covered. It avoids redundancy and maintains high information density.

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 essential context: what the tool does, when to use it, and what it explains (pricing, flow, authentication). Since there is no output schema, no return-value details are needed, and the description is sufficiently complete for an agent to invoke it correctly.

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 no parameters, so there is nothing to explain. The description does not need to add parameter information; schema coverage is complete by default.

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 explicitly states the tool's purpose: to explain what Nautilinks does, how its backlink service works, and how an AI agent can use it. It clearly distinguishes this informational tool from the action-oriented siblings like create_order or check_balance.

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?

It provides explicit usage instructions: 'Use this when the user asks what Nautilinks does...' and even recommends calling it first when unsure about the service. This leaves no ambiguity about when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral context: the balance is applied after discounts, full coverage settles immediately, partial coverage reduces the Stripe remainder, and an API key is required. This goes beyond the 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?

Three sentences, each with a distinct purpose: when to use, how the result is used, and a requirement. No redundancy, and the usage guidance is front-loaded.

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 read-only, no-parameter tool, the description covers everything an agent needs: what it returns, when to call it, how the result affects create_order, and the auth requirement. No output schema exists, but the return value is self-evident.

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 baseline is 4. The description adds context that the balance is scoped to the API key, which clarifies how the tool knows whose balance to return, even though no parameters are 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?

States a specific verb and resource: 'return the prepaid balance available to this API key'. It differentiates from siblings by explicitly linking to create_order, making its role clear without ambiguity.

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?

Provides explicit when-to-use guidance ('Use this before create_order') and explains how the balance is consumed, which is strong context. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses the critical behavioral traits: it can spend prepaid balance immediately, it can produce a payment_url requiring human checkout, it applies promo/welcome offers, and it explicitly instructs the agent to 'surface that link and the total and never imply the purchase is complete.' These are the high-stakes side effects an agent needs to know.

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 dense but every sentence earns its place by introducing a decision-critical piece of knowledge: use condition, balance impact, item shape, article_id source, checkout behavior, optional check_balance, and required auth scope. It is well accumulated with the riskiest information placed early.

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?

Despite having no output schema, the description tells the agent what to do with the purchase result—surface the payment_url and total and not claim completion—and clarifies partial vs full credit behavior, the need for a human checkout step, and the required 'order' scope. An agent has enough context to invoke this tool correctly and communicate the outcome safely.

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 even with no extra parameter detail in the description. The description echoes some parameter concepts—item format, tier-2 packs, project tag, article_id via list_site_articles—but these are already well documented in the input schema and add minimal new semantic meaning.

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 clear gate—'Use this only when the user has selected placements and wants to place a backlink order'—and then states a specific action: 'Place an order for 1 to 20 backlinks across catalog sites.' It clearly identifies this as the create/purchase tool and distinguishes it from the sibling list/status/quote tools.

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?

It provides explicit when-to-use guidance, prerequisites, and sequencing: calls list_site_articles first to get article_id, calls check_balance to determine whether the payment will be full or partial, and warns against implying completion. The description tells the agent how to behave before, during, and after invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint false. The description strengthens this by explicitly saying it creates no cart, quote, charge, or order, and by emphasizing the returned items are only for review. No contradiction with annotations; it just does not cover extra operational concerns like rate limits or auth.

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 three short sentences, front-loaded with the core action, followed by side-effect clarification and the intended next workflow step. Every sentence adds something useful; there is no repetition or filler.

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 single-parameter read-only tool with complete schema coverage, this is highly complete. The description explains what results mean and how to use them downstream via create_order. The lack of an output schema is adequately handled by calling the result 'configured backlink items' and indicating they are order-ready.

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% for the single required project_id, and the schema already mentions passing returned items to create_order. The description adds useful context beyond the schema: the project must be owned, and the relevant opportunities are the latest uncited fan-out. This is modest but real added meaning.

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 and resource: it turns latest uncited fan-out opportunities from an owned AI-visibility project into configured backlink items. The title reinforces this as building order-ready items, and the explicit distinction from purchasing (create_order) helps separate this tool from its siblings.

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 direct usage guidance: it is a read-only preparation step and the returned items should be reviewed and then passed to create_order. It names the relevant downstream tool, though it does not explicitly describe when-not-to-use it or compare it to related list-oriented tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral context by listing the pipeline stages, the returned fields (anchor_text, target_url, published_url), and the API key requirement, going beyond the 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?

Two efficient sentences with no fluff: one states the use case, the other describes the output and pipeline. The most important scoping language is front-loaded.

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 single-parameter read tool with one output schema, this description covers the trigger, the resource, the returned fields, the workflow stages, and the authentication requirement. Nothing necessary for correct invocation 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?

Schema description coverage is 100%, and the schema already explains that order_id can come from list_orders or get_quote_status. The description does not add new parameter-level detail, but the schema carries the semantic weight, so baseline 3 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 states a specific action ('Fetch the status') on a specific resource ('each backlink item' for 'a specific order'). It also clarifies the exact use case (publication progress or live URL), making it distinct from list-level tools like list_orders.

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 opens with an explicit trigger: 'Use this when the user wants publication progress or the live URL for a specific order.' It clearly scopes this tool to one order, though it does not explicitly name alternatives or when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by noting that this is a polling operation for an async payment flow, that conversion yields an order_id, and that authentication requires a Nautilinks API key.

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 with the key usage instruction. A small redundancy exists between the first and third sentence, but each sentence still earns its place by contributing timing, purpose, output, or auth context.

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 single-parameter, read-only tool, the description provides sufficient operational context: when to poll, what info to expect (order_id once converted), and the auth requirement. It does not enumerate possible return states or explicitly contrast with get_order_status, but the core invocation context is complete enough.

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 fully describes quote_id, noting it is returned by create_order. The description merely repeats this same source without adding additional format, constraints, or edge-case semantics, so credit is not exceeded.

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 explicitly states the verb (check) and resource (quote payment status), and mentions the resulting order_id on successful conversion. This clearly distinguishes get_quote_status from sibling tools like get_order_status by focusing on the quote-to-order lifecycle.

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 clear usage timing: call after create_order returns a payment_url and after handing the URL to the user. It does not explicitly state when not to use it or name alternatives like get_order_status, but the sequential context makes the intended flow obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat that this is a non-mutating read. It adds extra context with 'Requires a Nautilinks API key' and the open-ended 'any other published attributes,' but it does not describe error behavior, invalid-id behavior, rate limits, or output shape variations.

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 front-loads the usage context in the first sentence, then gives an efficient purpose statement and a necessary API-key note. The list of fields is longer than strictly necessary, but it earns its place because there is no output schema.

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 single-parameter, read-only tool with full annotations and no output schema, the description says what the tool does, when to invoke it, what the return will contain, and which prerequisite it needs. An agent has enough context to select and call this tool correctly.

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 provides 100% documentation for site_id: 'The catalog site id, as returned by search_sites.' The description merely says 'by id' and does not enrich the parameter semantics further, so the schema already carries the documentation burden.

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: 'Fetch the full catalog record for a single site by id,' and enumerates the returned fields. It explicitly distinguishes this from the search_sites list stage by saying 'Use this after search_sites,' so it is not just a tautology of the tool name or title.

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 clear context: 'Use this after search_sites when the user needs to evaluate one backlink placement before buying.' It names the predecessor search_sites and the intended workflow stage, but does not explicitly state when not to use the tool or mention an alternative tool that should be selected instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds value by noting the response contains a 'returned project id', implying what the output yields, and mentions 'owned by this account' as a scoping constraint—details not present in the annotations. No contradiction exists.

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 with no filler. The primary purpose is front-loaded, and the follow-up usage hint is placed logically after the main action. Every word earns its place, making it a model of conciseness and structure.

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 no parameters and no output schema, the description provides all necessary context: what it lists, the account ownership, and how to use the result. It even mentions the response contains project ids, which is essential for chaining. Nothing an agent needs to call it correctly 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 input schema has zero parameters, so there is nothing to describe beyond the schema. Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description does not need to clarify any parameters since none exist, and it correctly omits irrelevant parameter details.

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 'List', the resource 'AI-visibility projects', and the scope 'owned by this account'. It distinguishes itself from sibling tools like list_orders by specifying the exact resource type, leaving no ambiguity about what it operates on.

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 explicit usage guidance: 'Use a returned project id with get_ai_visibility_plan to build order-ready backlink items.' This tells the agent exactly how to chain the result with a specific sibling tool. It does not explicitly exclude other tools, but given the simplicity of the tool, the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context beyond those: results are scoped to the API key and include overall status and totals. It does not mention pagination or limits, but given the annotations cover the safety profile and the operation is a simple list, this is a strong disclosure.

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 with no filler. The condition for use is front-loaded, followed by the scope and content of results, then the sibling alternative and prerequisite. Every sentence contributes distinct, necessary 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 zero-parameter, read-only list operation with annotated safety and clear sibling routing, the description is nearly complete. It states output contents at a useful level (overall status and totals), though it doesn't describe the exact response shape or pagination behavior. Since there is no output schema, a bit more detail on response format could help, but the core invocation context is fully covered.

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 schema description coverage is 100%, so there is nothing for the description to add about parameters. Per the baseline for zero-parameter tools, this is appropriately handled; no parameter detail is missing.

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 states a precise verb-resource pair: 'List orders placed with this API key, including overall status and totals.' It also differentiates from the sibling get_order_status by framing this as the order-level list while the sibling is for per-link detail. Scope and outcome are unmistakable.

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?

It explicitly says when to use: when the user wants order history or needs to find an order id. It names the alternative get_order_status for per-link detail on a specific id and states the API key prerequisite. This gives an agent clear routing guidance with no inference needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already provide readOnlyHint, idempotentHint, and non-destructiveHint. The description goes beyond that by noting the auth requirement, the 'sold-once' scoping, and the returned ranking/impression data. There is no contradiction with the 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?

The description is compact and efficiently structured: first the action, then the return shape and purpose, then the prerequisite API key. Every sentence earns its place and the most important scoping information is front-loaded.

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?

Even without an output schema, the description names the key returned dataset (article_id, ranking queries, positions, impressions) and explains how to proceed with it. The two-parameter input is simple, the auth requirement is called out, and the tool is fully actionable.

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 description coverage is 100%, so the schema already documents site_id and limit clearly. The description adds little about parameter semantics beyond contextualizing site_id as a catalog site, which matches the expected baseline.

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 states a clear verb ('List') and a specific resource ('sold-once existing articles...on one catalog site'), and it identifies the key output (article_id) that feeds later steps. This clearly distinguishes it from sibling tools such as create_order, get_order_status, and list_ai_visibility_projects.

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?

It gives the workflow: list articles, choose a page, then pass article_id to create_order with format=lien_insere. It also notes the required API key. It does not explicitly state when-not-to-use or reference alternative list tools, but the workflow context is sufficient for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a required API key and outlines the return payload (domain, metrics, price, id) plus pagination via offset and total count. This goes beyond annotations by explaining authentication and the shape of results.

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?

Two sentences pack a lot of information efficiently: the first covers usage and filters, the second covers returns and prerequisites. The most important information (what it does) is front-loaded, and every clause earns its place—no redundant phrasing.

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 read-only search tool with 8 optional parameters, all fully described in the schema, the description covers the key operational details: the return fields, pagination, and the required API key. It does not need to explain the schema because that is self-contained, and the description fills the gaps that the schema cannot (return shape, authentication, and the relationship to downstream tools).

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 description coverage is 100%, and the parameter descriptions are already detailed (e.g., shelf enum explains the tiers). The tool description merely summarizes the filter set without adding new semantic meaning beyond the schema. It does not clarify parameter syntax or edge cases, so a baseline 3 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 opens with a specific verb and resource ('Search the Nautilinks catalog') and enumerates the filter dimensions (niche, language, Trust Flow, price, shelf, free-text). It clearly distinguishes this from related tools by noting that the returned site id is 'needed for get_site and create_order', which tells an agent exactly when this tool is the entry point.

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?

It states the trigger condition ('when the user wants to find or compare websites where they can buy backlinks') and implies when not to use it, e.g. if you already have a site id you would use get_site, since the description says the id is needed for those tools. It doesn't explicitly name alternatives, but the context makes the intended usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.