Skip to main content
Glama

XDaLa Workflow Builder

by io.github.xgr-network

Create XDaLa session start handoff

create_xdala_session_start_handoff
Idempotent

Prepare and store a read-only xgr-session-start@1 handoff for xDaLa Workbench. Use this tool whenever the user wants to start, run, launch, execute, queue, or prepare an XDaLa session. Use this tool for starting an existing deployed XRC-729/XRC-137 workflow, starting from a runtime XRC-729 orchestration, starting from a bundle deploy result, or importing a canonical xgr-session-start@1 request into xDaLa Manage Sessions. When explaining required input to users, use canonical xgr-session-start@1 terminology: sessions[].orchestration, sessions[].ostcId, sessions[].stepId, sessions[].payload, sessions[].maxTotalGas. Do not ask users for entryStepId; entryStepId is not the Workbench Session Start field. For deployed XRC-729 workflows, first inspect the runtime, identify ostcId and the likely entry step, resolve that step's XRC-137 rule, derive required payload fields from the XRC-137 payload schema, treat fields with defaults as optional, and present required and optional/default fields before creating a handoff. Do not call this tool with guessed payload values. If required start payload fields are missing, first present the required fields to the user and ask for values or explicit permission to use demo values. Only use demo/dummy/example/default values when the user explicitly asks or accepts them. This tool returns a Workbench xdalaUrl such as https://xdala.devnet.xgr.network/session-start/ss... . The agent must show the returned xdalaUrl to the user. Do not replace the xdalaUrl with a generic /operations/op... link. The MCP does not sign, submit, or execute. xDaLa Workbench performs local signing and calls xgr_validateDataTransfer. Do not describe the XRC-729 contract owner as the owner of a not-yet-started session; owner()/getOwner() and getExecutorList() identify start-authority roles only. Use sessions[].starterAddress only as an intended starter when explicitly set, and use terminal result data such as result.results[].owner/sessionId/pid for the actual session owner/starter after Workbench start.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uiNoOptional user-interface metadata for Workbench import and display.
expiryNoUnix timestamp or expiry value for the prepared request.
ostcIdNoOrchestration step contract id for the XDaLa workflow.
sourceYesSource type for deriving the prepared XDaLa request.
stepIdNoCanonical XDaLa step id used by Workbench/session-start requests.
chainIdNoNumeric EVM chain id for the target network.
networkYesTarget network name or environment, for example mainnet or devnet.
payloadNoStructured payload object for an XDaLa step or workflow request.
requestNoCanonical request object used by the target XDaLa workflow operation.
signingNoSigning metadata for Workbench or local wallet handoff preparation.
summaryNoStructured summary metadata for human review and audit context.
ostcHashNoHash or identifier of the orchestration step contract artifact.
securityNoOptional security metadata for handoff preparation.
sessionsNoArray of canonical xgr-session-start@1 session requests.
executionNoExecution metadata for prepared XDaLa workflow requests.
ttlSecondsNoTime-to-live in seconds for temporary offchain handoff data.
maxTotalGasNoMaximum total gas budget allowed for the prepared XDaLa session request.
orchestrationNoAddress or identifier of the deployed XDaLa orchestration contract.
walletAddressNoWallet address used as intended signer, starter or actor context.
executorGrantsNoExecutor grant metadata for prepared XDaLa session-start requests.
expectedSignerNoExpected wallet address that should sign or execute the prepared handoff.
bundleDeployHandleNoOpaque handle returned by a previous XDaLa bundle deploy handoff flow.

Output Schema

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

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already provide readOnlyHint=false/idempotentHint=true, and the description adds valuable behavioral context: 'The MCP does not sign, submit, or execute', Workbench performs local signing and xgr_validateDataTransfer, and the returned xdalaUrl must be shown to the user. It also clarifies authority-role semantics and warns against describing owner()/getOwner() as the session owner. The 'read-only handoff' wording refers to the artifact type, not the tool operation, so it does not contradict the annotations.

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 dense and front-loaded with the core purpose, but it is long and contains some redundancy in the usage triggers ('Use this tool whenever...' and 'Use this tool for...'). Every sentence nonetheless earns its place by adding a meaningful constraint or workflow step, which is appropriate for a complex 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?

For a 22-parameter nested tool with an output schema, the description covers the full workflow: source types, preconditions, payload derivation, demo-value guardrails, output URL expectations, and post-return behavior. It also addresses edge cases like owner/starter role semantics, making it complete for an agent to invoke correctly.

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 100%, so the baseline is 3, but the description adds significant meaning beyond the schema. It explains canonical xgr-session-start@1 terminology, how to derive required payload fields from XRC-137 rules, treats fields with defaults as optional, and explicitly says not to ask users for entryStepId. This process-level guidance greatly helps select and fill parameters correctly.

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 explicitly states 'Prepare and store a read-only xgr-session-start@1 handoff for xDaLa Workbench' with a specific verb and resource. It also enumerates the exact trigger scenarios ('start, run, launch, execute, queue, or prepare an XDaLa session') and distinguishes this tool from bundle-deploy and operation handoff tools by scope.

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 explicit usage triggers ('Use this tool whenever...') and lists valid source types (runtime, bundle deploy result, direct/canonical import). It also provides strong prohibitions: 'Do not call this tool with guessed payload values', 'Do not replace the xdalaUrl with a generic /operations/op_... link', and instructs to ask the user for missing required fields rather than guessing.

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