Skip to main content
Glama

Recover only original captured analytics responses after a stopped or interrupted request

native.genads_recover_analytics
DestructiveIdempotent

Recover only original captured analytics responses after a stopped or interrupted request. This starts no token exchange or missing report page. Partial reports and source caveats remain visible.

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": {
      "work_id": "<work_id>",
      "arguments": "<arguments>",
      "expected_catalog_version": "<expected_catalog_version>",
      "read_skills": "<read_skills>",
      "request_key": "<request_key>"
    },
    "name": "native.genads_recover_analytics"
  }
}

Input Schema

NameRequiredDescriptionDefault
work_idYes
argumentsYes
read_skillsYesExact required native skills and their dependencies, copied from the accepted session bootstrap's skills array. Include only entries in that array. General mcp.* guides and native.{studio}.instructions are guidance, not native skill proofs.
request_keyYes
publication_proposal_idNoFor native Social scheduling, the exact server-approved publication proposal. This identifier cannot confer approval by itself.
expected_catalog_versionYesFor a new session, read a studios/{studio}/native/{pack} child toolset and copy invocation.catalog_version from a native tool descriptor. Do not use the top-level library version. For calls in an existing session, use that session proposal's catalog_version.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

The annotations already declare openWorld, idempotent and destructive, and the description adds real context beyond them: no token exchange is initiated and partial reports plus source caveats stay visible in the returned state. However, it never explains the destructive side of the operation — what state is consumed or replaced by the recovery — so the risky half of the behavior stays undisclosed.

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?

Three short sentences with the core action front-loaded and zero filler. The phrasing "no token exchange or missing report page" is idiomatically compressed and takes a moment to parse, but nothing is redundant.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and the recovery scenario is covered. What is missing is the operational contract for a destructive, open-world tool: which parameters identify the interrupted request, what happens to the original request afterward, and what the caller must have prepared before invoking.

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

Parameters2/5

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

Six parameters at 50% schema coverage, and the description mentions none of them. The non-obvious session parameters (work_id, request_key, read_skills, expected_catalog_version, publication_proposal_id) rely entirely on partial schema text, and nothing here clarifies how request_key ties to the interrupted request being recovered.

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?

"Recover only original captured analytics responses after a stopped or interrupted request" gives a specific verb (recover), a specific resource (captured analytics responses), and a precondition (stopped/interrupted request). It implicitly separates this from native.genads_analytics_request / native.genads_refresh_analytics by saying it starts no token exchange or missing report page, though it never names those siblings.

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

Usage Guidelines4/5

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

The trigger condition is explicit: use this after a stopped or interrupted request. The second sentence effectively states when-not (do not use this to kick off a token exchange or fetch a missing report page), which steers the agent toward the request/refresh siblings. It stops short of naming the alternative tool to call instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources