Skip to main content
Glama
Downshift

Rivalize MCP Server

by Downshift
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Read a report

get_report
Read-onlyIdempotent

Read a competitive-intelligence report as Markdown, or fetch only the section, competitor, or page you need to answer a specific question.

Instructions

Read one competitive-intelligence report as Markdown: TL;DR, biggest threat, your blind spots, a section per competitor, and cited battlecards where the report has them.

Claims the report's fabrication check flagged are shown as "[removed — unverified]", exactly as in the report itself. Do not try to fill them in.

Args:

  • report_id (string, required): the report id (or its job id) from list_reports

  • section (string, optional): only this named section, plus the report title, date and depth, and a line naming the report's other sections. A whole report is several thousand to over a hundred thousand characters and a section is typically a sixth of it, so ask for the section your question needs. Sections: tldr, biggest-threat, blind-spots, actions (what your product should do), battlecards, competitors (every competitor's section in full); per competitor, gathered from every competitor's section: pricing, momentum, app-store, strengths, weaknesses, key-findings, creators, ads, tech-stack. A report has only the sections it has data for. A name that is not one of this report's sections is an error that lists the sections it does have; retry with one of them. Case, spaces and underscores are ignored ("Key findings" = key-findings).

  • competitor (string, optional): only the sections whose heading names this competitor (its section and its battlecard), plus the report title and date. Case-insensitive. With section, only that competitor's part of the section (e.g. section "pricing" + competitor "Notion").

  • page (number, optional): 1-based page. A report over 25,000 characters is split into pages at section boundaries; every page starts with "Page N of M", the characters that remain, the exact call for the next page, and the sections on later pages. A report that fits is returned whole, unchanged.

Without section, returns the whole report exactly as before. Returns Markdown. 404 if the report is not in your account or is not available.

Use when: "summarise my latest report" (no section, or tldr), "what do competitors charge?" (section "pricing"), "what did the report say about ?" (use competitor).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page of a long Markdown document; every page is under 25,000 characters
sectionNoReturn only this named section of the report: tldr, biggest-threat, blind-spots, competitors, battlecards, actions, pricing, momentum, app-store, strengths, weaknesses, key-findings, creators, ads, tech-stack
report_idYesReport id (or its job id) from list_reports
competitorNoReturn only the sections whose heading names this competitor

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), yet the description adds real behavioral context: fabrication-flagged claims render as '[removed — unverified]' and must not be filled in, a bad section name errors and lists available sections, paging kicks in above 25,000 chars at section boundaries with 'Page N of M' headers and a next-page call, and a 404 is returned when the report is out of scope.

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?

Information-dense and front-loaded (return format first, then args, then routing examples), and the nested arg list is easy to scan. It is nonetheless long, and a few statements restate each other (whole-report default behavior, Markdown return format) — minor redundancy rather than padding.

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?

No output schema exists, so the description carries the return contract itself: Markdown, section-per-competitor layout, citation/removal markers, page headers with remaining characters and the next-page call. Combined with the error and paging semantics, an agent has everything needed to call it correctly and interpret the result.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds meaning the schema cannot: the full section vocabulary including both whole-report sections and per-competitor gathered sections (pricing, momentum, ads, tech-stack), the interaction rule that 'section + competitor' returns only that competitor's part of the section, case/spaces/underscore normalization ('Key findings' = key-findings), and that absent sections are an error listing what exists.

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 precise verb and resource ('Read one competitive-intelligence report as Markdown') and enumerates the actual content shape (TL;DR, biggest threat, blind spots, competitor sections, battlecards). It is clearly distinguishable from sibling list_reports, which it explicitly references as the source of report_id.

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?

Ends with an explicit 'Use when:' block mapping real user questions to parameter combinations ('summarise my latest report' -> no section or tldr; 'what do competitors charge?' -> section pricing; 'what did the report say about <competitor>?' -> competitor). It also tells the agent when to narrow to a section (size: several thousand to 100k+ chars, a section ~1/6) and when to page.

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