Skip to main content
Glama
Sign In
Rivalize MCP Server

Rivalize MCP Server

by Downshift
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Check a report run

get_report_status
Read-onlyIdempotent

Check if a report started with run_report has finished by passing its report_id, then use the returned status to decide whether to wait or retrieve the results.

Instructions

Check whether a report started with run_report has finished. Reading is free. A full report takes about 10 to 20 minutes.

POLL NO MORE OFTEN THAN EVERY 30 SECONDS. Each call is counted against your API allowance and the report cannot finish faster; tell the user it is running and check again later instead of calling in a loop.

Args:

  • report_id (string, required): the report_id from run_report

Returns JSON: { data: { report_id, status, finished, message, ... } }. status: "processing" (still running), "completed", "no_competitors" (finished: a profile of the product alone), or "no_rivals" (stopped before any research because no competitor could be counted as a rival; no credits were used). The API does not report a percentage: status is all there is. When finished is true the result names the next call: get_report with the report_id.

Use when: "is my report ready?" after run_report.

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": {
      "report_id": "<report_id>"
    },
    "name": "get_report_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
report_idYesThe report_id returned by run_report (or an id from list_reports)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses quota impact ('each call counted against your API allowance'), expected latency (10-20 minutes), and the credit implications of the 'no_rivals' outcome. It also warns that no percentage is available, preempting a false expectation about the return payload.

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?

Front-loads the core check, then the polling constraint in caps, then args and returns. Nearly every sentence earns its place, though the inline return-value narrative is somewhat long for a tool with a single string parameter.

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

Completeness5/5

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

With no output schema, the description carries the return shape itself, enumerating all four status values with their meanings and the terminal next step. For a one-parameter polling tool, an agent has everything needed to call correctly and interpret the result.

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

Parameters4/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 report_id, but the description reinforces its provenance ('the report_id from run_report') and ties it to the producing call. That is a modest value-add over an already complete schema rather than new syntax or format guidance.

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

Purpose5/5

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

States a specific verb and resource ('Check whether a report started with run_report has finished') and cleanly separates this polling tool from run_report (which starts it) and get_report (which fetches results once ready). An agent can distinguish it from all 15 siblings without opening a schema.

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

Usage Guidelines5/5

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

Explicit 'Use when: "is my report ready?" after run_report' plus a hard operational rule (poll no more often than every 30 seconds), a rationale (the report cannot finish faster), and a prescribed alternative behavior (tell the user it is running instead of looping). It also names the follow-up call (get_report) once finished is true.

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

Deploy Server

Other Tools