Webanto

Read attributed backlink attempt report

webanto_get_backlink_report

Read-onlyIdempotent

Read ten attempt summaries per live page within an explicit UTC creation-date range of at most 90 days. Original API key only. Separates client-reported submissions, historical verification dates and latest independent observation outcomes. No external fetch, inference credits or indexing/ranking claims. Follow next_cursor while retaining the date range; live pages may shift as attempts change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "to": "<to>"
    },
    "name": "webanto_get_backlink_report"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Exclusive UTC attempt creation time. Reports only this originating API key.
`from`	Yes	Inclusive UTC attempt creation time. Range must be at most 90 days.
`cursor`	No	Next cursor from the previous page, retaining the same date range. Omit for the first page.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, closed-world and non-destructive, yet the description still adds real behavior: authentication scope ('Original API key only'), a data-provenance split between client-reported submissions, historical verification dates and latest independent observations, and a pagination stability caveat ('live pages may shift as attempts change'). The billing/scope disclaimers ('inference credits', 'no indexing/ranking claims') are useful but phrased cryptically enough to cost a point.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the core operation and the range constraint before the caveats and pagination note. No filler, though several clauses are compressed to the point of being harder to parse than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return shape needn't be explained, and the description covers auth scope, date-range limits, pagination continuation and data provenance. The remaining gap is the ambiguous term 'live page' and how the ten summaries are grouped per page, which an agent may misread.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents from/to inclusivity, exclusivity, UTC format and the 90-day ceiling, and the cursor's reuse rule. The description largely restates those facts; its only added meaning is that the report is scoped to the calling API key and that the cursor must be used with the same range. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read ... attempt summaries per live page') plus the hard scope constraint (explicit UTC creation-date range, max 90 days). This distinguishes it in spirit from the single-attempt sibling webanto_get_backlink_attempt, but no sibling is named, so an agent must infer the boundary rather than read it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through constraints ('Original API key only', follow next_cursor while retaining the date range) and through the explicit exclusions (no external fetch, no indexing/ranking claims). However, there is no explicit statement of when to pick this report over webanto_get_backlink_attempt or webanto_list_backlink_opportunities, which is the main decision an agent faces.

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

All Webanto tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?