Skip to main content
Glama
ruya-grp

fusion-query-mcp

by ruya-grp

fusion_prepare_action

Read-onlyIdempotent

Preview an action without sending anything: validate the payload, catch forbidden requests, and receive a token to commit only after explicit user approval.

Instructions

Check an action and hold it for confirmation. Sends NOTHING to the pod.

Returns exactly what would travel, the guard's verdict, and a token. The action reaches Fusion only when fusion_commit_action presents that token.

Show the preview to the user in their own words and get an explicit yes before committing. That pause exists here because Fusion has none: an authorised, valid POST executes on arrival.

This cannot tell you the action will succeed. There is no dry-run for a Fusion create -- a valid POST commits -- so the pod has not seen this payload yet. What it can do is stop an action the policy forbids, and show you the fields the snapshot says are required before you spend a round trip.

Args: resource: e.g. purchaseRequisitions. Use fusion_api_list_actions to see what this account may actually create. payload: The record to send. Resolve every id with fusion_resolve_value first. verb: POST to create, PATCH to change an existing record. record_id: Required for PATCH -- the record to change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
verbNoPOST
payloadYes
resourceYes
record_idNo

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

A5/5.0
Behavior5/5

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

Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, the description adds essential behavioral context: no payload is sent, a validation token is produced, and Fusion applies no confirmation pause. It also warns that prepare does not guarantee success and is not a dry-run. This goes far beyond what the annotations alone convey.

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 front-loaded with the most critical fact ('Sends NOTHING to the pod') and every sentence earns its place by adding either workflow, limitation, or parameter semantics. The structure moves from behavior to workflow to caveats to arguments, making it easy for an agent to parse. It is longer than minimal, but the length is justified by the safety-critical nature of the tool.

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 is complete for a safe-preview tool of this complexity: it covers behavior, outputs, workflow, limitations, and parameter semantics, and it references the output schema rather than duplicating return details. It also explains why this tool exists given Fusion's lack of a confirmation pause. Nothing an agent needs to call 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 schema description coverage at 0%, the description carries the full burden and does so well. It explains resource with an example and how to discover valid values, payload with an id-resolution prerequisite, verb with POST/PATCH semantics, and record_id as required for PATCH. Every parameter gains meaning beyond its schema title or default.

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 states a specific verb and resource: it checks an action and holds it for confirmation, explicitly saying it sends nothing to the pod. It also distinguishes itself from fusion_commit_action by explaining that the action only reaches Fusion when that sibling presents the returned token. This is exactly what an agent needs to tell this tool apart from its siblings.

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?

The description gives clear when-to-use guidance: show the preview to the user, get explicit yes, then commit via fusion_commit_action. It also names supporting siblings (fusion_api_list_actions for valid resources, fusion_resolve_value for ids) and explains what the tool cannot do, preventing misuse as a dry-run. This is explicit workflow-level guidance, not just a vague hint.

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