Skip to main content
Glama
raportagent

RaportAgent MCP Server

by raportagent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript

RaportAgent MCP server

A Model Context Protocol server that puts RaportAgent inside any MCP client — Claude Desktop, Claude Code, Cursor. Ask your assistant to research a market or map a regulatory landscape, and it generates a sourced RaportAgent report, then pulls the finished markdown and its audit trail.

Thin wrapper over the RaportAgent REST API (/v1), so it inherits per-key rate limits, the credit model, and the audit trail unchanged.

Tools

Tool

What it does

generate_report

Start a report (query, optional template: compliance/pitch/saas/ecommerce/realestate/local/battlecard/duediligence/fintech). Returns a report_id; optionally polls with wait_seconds. Costs 1 credit (2 for battlecard).

get_report_status

queued / running / completed / failed

get_report

The finished report's full markdown + sections

get_report_audit

Provenance: AI models, agents, source counts, SHA-256 of the exact content

get_report_sources

Every cited source with link-health counts (working / uncertain / dead)

cancel_report

Cancel a queued/in-progress report and refund its credit

list_reports

Your recent reports

get_account

Remaining credits and plan

Related MCP server: aicard

Setup

  1. Get an API key: RaportAgent → My account → API keys (an ra_live_… key).

  2. Register it with your MCP client — no clone, no build, npx pulls the published package.

Claude Desktop

Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):

{
  "mcpServers": {
    "raportagent": {
      "command": "npx",
      "args": ["-y", "@raportagent/mcp"],
      "env": {
        "RAPORTAGENT_API_KEY": "ra_live_xxx"
      }
    }
  }
}

Claude Code

claude mcp add raportagent -e RAPORTAGENT_API_KEY=ra_live_xxx -- npx -y @raportagent/mcp

Cursor

Same command/args/env shape as Claude Desktop above, under Cursor's MCP settings.

Running from source (contributing / debugging only)

git clone https://github.com/raportagent/raportagent-mcp.git
cd mcp-server
npm install
npm run build

Then point command/args at node / dist/index.js with an absolute path instead of npx.

Config

Env

Default

Notes

RAPORTAGENT_API_KEY

—

Required. ra_live_… key.

RAPORTAGENT_BASE_URL

https://raportagent.com

Override for self-hosted / staging.

Notes

  • Generation typically takes ~15 minutes. generate_report returns immediately with a report_id; the assistant should poll get_report_status (or pass wait_seconds) before get_report.

  • stdout is the MCP transport — the server logs only to stderr.

  • The API key is only ever sent to your configured RAPORTAGENT_BASE_URL.

Available Tools

4 tools
get_accountA

Show your RaportAgent account: remaining credits and plan.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations provided. Description indicates a read-only retrieval of account info, but does not disclose any potential side effects, authentication needs, or rate limits.

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

Conciseness5/5

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

Single sentence, front-loaded with the verb 'Show', no unnecessary words.

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?

For a zero-parameter, simple info retrieval, the description covers the essential purpose and output. Could mention if results are cached but not necessary.

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?

No parameters exist, so schema coverage is 100%. The description adds context about the output (credits and plan), which is helpful.

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?

The description clearly states the tool shows RaportAgent account details (remaining credits and plan), which is distinct from sibling tools focused on reports.

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?

No explicit when-to-use or when-not-to-use guidelines. The context implies it's for account info queries, but alternatives are not discussed.

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

get_reportA

Fetch a completed report's full markdown content and section list.

ParametersJSON Schema
NameRequiredDescriptionDefault
report_idYesThe rep_… id.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations provided, so description bears full burden. Discloses that the report must be completed and what is returned, but does not mention error conditions, permissions, or side effects. Adequate but not exhaustive.

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

Conciseness5/5

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

Single sentence, 10 words, front-loaded with key information. No wasted words or redundant content.

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?

For a simple tool with one required parameter and no output schema, the description specifies the output type ('full markdown content and section list') but lacks detail on the structure of the section list. Adequate but incomplete given no output schema.

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 covers the single parameter with a description ('The rep_… id.'). Description adds context that the report must be completed, but does not significantly enhance meaning beyond schema. Baseline of 3 is appropriate.

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?

Description clearly states the action ('Fetch') and the resource ('completed report's full markdown content and section list'). Differentiates from siblings like get_report_status, get_report_audit, and get_account.

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?

Implies the tool is for fetching content of completed reports, but does not explicitly state when not to use it or compare to alternatives. Context from sibling names helps but lacks direct guidance.

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

get_report_auditA

Get a report's audit trail / provenance: AI models, agents, source counts, and a SHA-256 of the exact content. Useful for compliance review and verifying a report has not been altered.

ParametersJSON Schema
NameRequiredDescriptionDefault
report_idYesThe rep_… id.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses what the tool returns (audit trail details) and implies read-only behavior. It does not mention permissions or side effects but is fairly transparent for a read tool.

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

Conciseness5/5

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

The description is two sentences: the first states what it does and lists outputs, the second provides use cases. No redundant words, effectively front-loaded.

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?

Given low complexity (one parameter, no output schema), the description adequately covers purpose and outputs. It could mention that it returns only audit data, not the full report, but is otherwise complete.

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% for the single parameter report_id, which is described as 'The rep_… id.' The description adds no additional meaning beyond the schema; baseline score is appropriate.

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?

The description uses a specific verb ('Get') and resource ('report's audit trail / provenance'), and lists concrete outputs (AI models, agents, source counts, SHA-256). It clearly distinguishes from siblings: get_report_status, get_report, and get_account.

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 description explicitly states usefulness for compliance review and verifying alteration, implicitly guiding when to use. It does not explicitly say when not to use, but the sibling tools provide context.

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

get_report_statusA

Check whether a report is queued, in_progress, completed, failed, or cancelled.

ParametersJSON Schema
NameRequiredDescriptionDefault
report_idYesThe rep_… id from generate_report.

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses return status values but does not state if the operation is read-only or any side effects. No contradiction with annotations.

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

Conciseness5/5

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

Single sentence, front-loaded with purpose and status options. No wasted words; every part delivers value.

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?

Given no output schema, description appropriately lists possible statuses. Could explain what each status signifies, but self-explanatory. Complete for a simple status check tool.

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% and description adds context beyond schema: 'The rep_… id from generate_report' clarifies the parameter origin. Adds meaningful 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?

Description clearly states the tool checks report status and lists possible statuses (queued, in_progress, completed, failed, cancelled). Distinguishes from siblings like get_report (full data) and get_report_audit (audit trail).

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?

No explicit guidance on when to use vs alternatives. Context suggests it's for status checking only, but lacks when-not conditions or alternatives like get_report for full details.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.3
    • First observedget_account
    • First observedget_report
    • First observedget_report_audit
    • First observedget_report_status
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct aspect: status, content, audit trail, and account info. There is no functional overlap.

Naming Consistency5/5

All tools follow a consistent 'get_<noun>' pattern, making it predictable for an agent.

Tool Count5/5

With four tools, the set is well-scoped for a reporting and account service—neither overly sparse nor bloated.

Completeness2/5

The tools are entirely read-only; missing essential CRUD operations like creating, cancelling, or listing reports, which are critical for end-to-end report management.

Maintenance

ActivitySlowing
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers