Skip to main content
Glama

XDaLa Workflow Builder

by io.github.xgr-network

Get XDaLa process Mermaid

get_xdala_process_mermaid
Read-onlyIdempotent

Render an XDaLa XRC-729 process graph from runtime, bundle, or bundle handoff data as Mermaid flowchart text. Read-only; does not sign, submit, or execute transactions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bundleNoCanonical XDaLa bundle JSON object to validate, store or hand off.
handleNoOpaque handoff handle returned by a previous XDaLa MCP tool.
ostcIdNoOrchestration step contract id for the XDaLa workflow.
sourceYesSource type for deriving the prepared XDaLa request.
directionNoValue for the direction parameter.
includeRulesNoValue for the include rules parameter.
xrc729AddressNoValue for the xrc729 address parameter.
includeWarningsNoValue for the include warnings parameter.
includeAddressesNoValue for the include addresses parameter.
includeRuleSummaryNoValue for the include rule summary parameter.
includePayloadFieldsNoValue for the include payload fields parameter.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesStructured result data returned by the XGR MCP gateway.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the behavioral trait that it does not sign, submit, or execute transactions, which aligns with and expands on the annotations. No contradictions.

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 with zero wasted words. It front-loads the core action and immediately follows with a critical safety note. Every sentence earns its place.

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?

Despite the complexity of 11 parameters and a required source, the description is complete enough for the tool's purpose. It explains the input types and emphasizes read-only behavior. The presence of an output schema reduces the need to describe return values.

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%, so the schema already documents all 11 parameters. The description mentions 'from runtime, bundle, or bundle handoff data', which relates to the source enum parameter but adds no further meaning beyond the schema. Baseline score 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?

The description clearly states the verb 'render', the resource 'XDaLa XRC-729 process graph', and the specific output format 'Mermaid flowchart text'. It distinguishes this tool from siblings by specifying the output type, making the purpose unambiguous.

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 it is read-only and does not sign, submit, or execute transactions, providing clear context on when to use it. It implies usage for visualization rather than execution, but does not directly compare to sibling tools.

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

All XDaLa Workflow Builder toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

There are many overlapping session-listing tools (list_xdala_sessions, get_recent_xdala_sessions, find_latest_xdala_session, list_xdala_session_ids, get_latest_session_payload) and duplicate validation tools (validate_xdala_bundle is an alias for validate_xgr_multibundle). Descriptions help but boundaries are still unclear.

Naming Consistency4/5

The verb_noun snake_case pattern is consistent across nearly all tools (get_, list_, create_, cancel_, validate_). Minor inconsistencies include the alias validate_xdala_bundle and interchangeable verbs like get_ vs read_ vs resolve_ for similar read operations.

Tool Count1/5

With 95 tools, this is far beyond the 25+ threshold for 'too many'. While the domain is broad, the sheer number makes the tool surface unwieldy and difficult for an agent to navigate.

Completeness4/5

The tool set covers a wide range of operations: handoffs, session queries, transaction exploration, contract reads, validation, gas requests, and purchases. Minor gaps exist (e.g., no direct workflow editing tools), but overall the surface is remarkably complete.

Resources