Skip to main content
Glama
ruya-grp

fusion-query-mcp

by ruya-grp

fusion_run_report

Read-onlyIdempotent

Execute a registered BI Publisher report using chosen bind values; unknown parameters are rejected before calling to avoid running on defaults. Returns data with row counts and a truncation flag.

Instructions

Run one registered BI Publisher report with bind values.

The statement lives in the report's data model, written once by an administrator; you choose only the values for the binds it declares. That is the same trust boundary the Fusion UI enforces, and on a pod that refuses lexical substitution it is the only path that reaches the database at all.

Discover names and parameters with fusion_list_reports. An unknown report name, or a parameter the report does not declare, is rejected here -- before any round trip -- with a message listing what IS accepted; correct the call from that list rather than guessing, because a dropped parameter would run the report on its stored defaults and return a plausible wrong answer.

The report applies no row cap of its own, so max_rows is applied after the rows arrive: row_count is what you are given, rows_returned_by_report is what came back, and truncated is true when those differ.

Args: report: Registered report name, as listed by fusion_list_reports. params: Bind values, e.g. {"p_pattern": "%INVOICE%"}. Omitted parameters take the report's registered default. max_rows: Rows to return, clamped to the server's hard maximum. timeout_s: Per-call timeout in seconds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo
reportYes
max_rowsNo
timeout_sNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: unknown reports/params are rejected before any round trip, omitted parameters silently fall back to stored defaults yielding plausible wrong answers, row caps are applied after rows arrive, and truncated semantics are clarified. This is exactly the kind of non-obvious behavior an agent needs to know.

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?

The description is longer than average but each paragraph earns its place by covering validation behavior, fallback hazards, and row-count semantics. It is front-loaded with a clear one-line purpose and uses structure well. It could be tightened slightly, but the length is justified by the subtle failure modes it prevents.

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?

Given the output schema already describes the return shape, the description covers everything else an agent needs: how to discover valid inputs, exact validation semantics, dangers of dropped parameters, row-cap behavior, and per-parameter details. No important gap remains.

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 description coverage is 0%, so the description carries the full burden for parameter semantics. It explains each parameter meaningfully: report is a registered name, params are bind values with defaults, max_rows is clamped to the server maximum, and timeout_s is per-call. The included example {'p_pattern': '%INVOICE%'} makes the expected shape concrete.

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 first sentence states the exact action: 'Run one registered BI Publisher report with bind values.' This clearly distinguishes it from siblings like fusion_run_query and fusion_adhoc_query, which operate on ad-hoc queries rather than registered reports.

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 directs the agent to discover valid report names and parameters via fusion_list_reports, and explains when this is the only path to the database. It does not explicitly name alternatives to avoid, but the context strongly implies when to use this tool versus a query tool, so it is clear but not exhaustive.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ruya-grp/Fusion-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server