Skip to main content
Glama

elaichi__toolbox__execute

Run one real third-party action through a connection this toolbox reaches — send the Slack message, create the HubSpot contact, read the calendar — with the organization’s restrictions and the approval gate applied. This is the operation that reaches outside Elaichi: it does whatever the underlying provider tool does, and the provider may make it irreversible, so confirm the target and the arguments before calling it. toolbox_id comes from toolbox.list, where global:{the caller’s usr_… id} holds every tool they can run and is the right default; tool_name must match a name returned by toolbox.get for that same id exactly; arguments must satisfy that tool’s own input schema (send {} when it takes none). A STORED toolbox the caller does not own but reaches only via a "use" share still runs — that is delegation: the call executes through the pinning editor’s connection authority, not the caller’s own, and if that authority is later revoked the tool simply disappears from toolbox.get, unmet, rather than failing here. Returns the provider’s raw response, whose shape is defined by the provider, not by Elaichi. Use synthetic_tool.execute instead for a saved multi-step Elaichi tool. The same tools are usually advertised here individually under their own {account}__{tool} names too, or behind search_tools and execute_tool once there are many of them. Those reach the same accounts at the same cost — but they are a SEPARATE namespace, not aliases, so pick one path and stay inside it. This operation’s tool_name must be a name toolbox.get returned for this same toolbox_id; passing an advertised {account}__{tool} name, or one search_tools handed you, fails with a bare "Tool not found: " that says nothing about the namespace being wrong. To use the other paths, call the advertised tool directly by its own name, or pass a search_tools result to execute_tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argumentsYesArguments matching the tool’s own input schema from toolbox.get. Required — send {} for a tool that takes no arguments.
tool_nameYesExact tool name as returned by toolbox.get for that same id. Never invent or reformat it.
toolbox_idYesId from toolbox.list — `global:usr_…` (everything the caller can run), `connection:conn_…` (one account), or a stored `tbx_…`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark readOnly=false and openWorld=true; the description adds that the provider may make the action irreversible, that approval gates and organization restrictions apply, that delegated calls execute under the pinning editor's authority, and that revocation makes the tool disappear from toolbox.get rather than fail. No contradiction with 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 long but information-dense and front-loaded with purpose and risk. Some caveats around separate namespaces and failure modes could be tightened, but every major sentence adds value for preventing misuse.

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 an open-world execution tool with no output schema, it completely covers identifier sources, targeting rules, delegation auth, failure behavior, namespace pitfalls, and return shape. Nothing needed for correct use 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?

Schema coverage is 100%, but the description goes beyond schema: it explains how to obtain toolbox_id and identifies the global:{usr_...} default, requires exact name matching against toolbox.get, and clarifies arguments must satisfy the target tool's schema and be {} when none. This materially improves correct invocation.

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 specific verb and resource: run one real third-party action through a connection the toolbox reaches, with concrete examples (send Slack message, create HubSpot contact, read calendar). It explicitly contrasts with synthetic_tool.execute and the individually advertised tools, so an agent can distinguish it from siblings without inspecting schemas.

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?

It states exactly where toolbox_id comes from, that tool_name must match toolbox.get exactly, and that synthetic_tool.execute is the alternative for saved multi-step tools. It also warns that advertised {account}__{tool} names and search_tools results live in a separate namespace and will fail here, which is strong when-to-use/when-not-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources