Skip to main content
Glama
ruya-grp

fusion-query-mcp

by ruya-grp

fusion_health_check

Read-onlyIdempotent

Run a probe report to verify Oracle Fusion Cloud connectivity, validating credentials, report bind values, and XML parsing. Reports degraded status when transport works but no rows are returned.

Instructions

Verify the whole path to the pod: credentials, report, bind values, parsing.

Probes something that actually works: it runs the registered list_tables report with a narrow pattern, so a green answer proves credentials, the catalog path, the bind-parameter shape and the XML parser all at once. On a pod with no reports registered it falls back to the legacy lexical probe (SELECT 1 AS N FROM DUAL), which is also what detects whether that pod wants the flat or the item-wrapped parameterNameValues JSON when param_shape is auto.

status is degraded -- not ok -- when the round trip succeeded but the report returned no rows: the transport works and the report is wrong, which is a different problem from an unreachable pod.

Args: datasource: Configured datasource key to probe (legacy path, and the datasource summary). An unknown name is reported as an error. report: Report to probe with instead of list_tables. pattern: Value for the probe report's p_pattern bind.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reportNo
patternNo
datasourceNo

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.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, so the description does not need to restate safety. It adds valuable behavior: the `list_tables` probe strategy, the legacy `SELECT 1` fallback, the `param_shape` auto-detection nuance, and the `degraded` status meaning. This is rich behavioral disclosure.

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 organized in short, purposeful segments: purpose, probe behavior, status interpretation, then arg documentation. Every sentence carries diagnostic value, and the main purpose is front-loaded.

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?

The description covers behavior, fallback, error semantics, degraded status, and all parameters, while an output schema handles return-value details. Nothing essential for an agent to invoke it correctly is missing.

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?

With 0% schema description coverage, the description fully compensates by explaining all three args: `datasource` as the configured key with error behavior, `report` as a replacement for `list_tables`, and `pattern` as the `p_pattern` bind value. This goes well beyond the bare schema.

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 opens with a precise verb and target: 'Verify the whole path to the pod: credentials, report, bind values, parsing.' It clearly distinguishes this from sibling tools by framing it as an end-to-end probe that runs `list_tables`, unlike direct query/report tools.

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 use case is strongly implied: use this to check connectivity, credentials, and report plumbing in one shot, with `status` semantics for interpreting results. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for an agent to select it.

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