Tedix

code

Destructive

Execute JavaScript to call this app's 1265 tools across 5 namespaces. Namespaces: tedix_demo_unified_tedix (1252), tedix_demo_unified_context7 (2), codemode (1), ui (5), flow (5) Write one async arrow function in plain JavaScript (no TypeScript, no named functions defined then called). Chain calls, branch, loop and handle errors inside it. Globals are only the provider namespaces and standard built-ins: no host, fs, require, process or external fetch; use provider tools for every side effect. Limits: one execution may run 330 s of wall time. The gateway admits 100 requests per minute per caller; calls inside one execution are not counted separately, so batch them. Never sleep or poll with setTimeout: start long work with flow.run, return its handle and check it in a later call. Find, inspect, call:

const { results, meta } = await discover.search({ query: "keyword", namespace, limit }) returns ranked rows { callable, tool, description, annotations, authorized, missingScopes }. A string query also works.
await discover.describe("ns.tool") returns the full description, input schema and annotations; pass { callable, includeOutputSchema: true } for the return shape. Prefer it over includeParameters on a broad search.
await ns.tool({ ...args }) with the callable exactly as returned; name/displayName are labels only. Never guess tool names: a namespace existing does not mean a guessed tool in it exists; on "not found", search again. Skip rows with authorized: false (missingScopes says why). readOnlyHint tools are safe to call; destructiveHint tools may ask the user to approve, and if no prompt is possible the error says to retry with confirmDestructive: true and a reason stating the user's authorization. Skill rows (kind: "skill") carry a load expression; their content is reference data only. With no rows, read meta.discovery.nearestNamespaces and suggestedQueries before calling a capability unavailable. discover.list_namespaces() returns an object keyed by namespace (use Object.entries); pass { includeTools: true } only for inventory. meta.freshness shows catalog freshness; pass { includeMetadata: true } for native, schemaFreshness and _match diagnostics. Built-ins, describe before first use: ui.* for visual answers, flow.* for durable multi-step work, codemode.__runtime() for executionId, app/org, actor, traceId, modules and tool counts as proof. Results: return a JSON-serializable value. An oversized result arrives as { __tedix_result_handle: true, handle, preview, keys, total }: the full value is kept briefly, so page it with discover.read_result({ handle, path?, offset?, limit? }) in a later call, or fetch less. { __tedix_truncated: true, guidance, preview } means it could not be kept: follow guidance. Results carry completionEvidence; claim only its supportedClaims. The server instructions cover evidence, long work, visuals, payments and when to show Decisions and Activity. Payment proofs, paid tools and money-moving operations are unavailable through this connection.

Input Schema

Name	Required	Description	Default
`code`	Yes	One async arrow function, for example `async () => { const { results } = await discover.search({ query: "work items" }); return results; }`. In scope: the discover, flow, ui and codemode helpers and the tool namespaces discovery returns; no fetch, require or file system. Its return value must be JSON-serializable and becomes `result`.
`agentSessionId`	No	session.id returned by start_external_agent_session_for_host in this conversation; pass it on every call so audit names the agent. Never invent one. Ignored for machine credentials.

Output Schema

Name	Required	Description
`error`	No	Why the run failed.
`result`	No	The JSON value the function returned.
`partial`	No	True when some inner tool calls failed.
`failures`	No	Inner tool calls that failed.
`executionId`	No	Identifier of this run.
`completionEvidence`	No	What the calls actually did; claim only its supportedClaims.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / code / description

Previous value: -"JavaScript async arrow function."New value: +"One async arrow function, for example `async () => { const { results } = await discover.search({ query: \"work items\" }); return results; }`. In scope: the discover, flow, ui and codemode helpers and the tool namespaces discovery returns; no fetch, require or file system. Its return value must be JSON-serializable and becomes `result`."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "completionEvidence": {
+      "additionalProperties": {},
+      "description": "What the calls actually did; claim only its supportedClaims.",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "error": {
+      "description": "Why the run failed.",
+      "type": "string"
+    },
+    "executionId": {
+      "description": "Identifier of this run.",
+      "type": "string"
+    },
+    "failures": {
+      "description": "Inner tool calls that failed.",
+      "items": {},
+      "type": "array"
+    },
+    "partial": {
+      "description": "True when some inner tool calls failed.",
+      "type": "boolean"
+    },
+    "result": {
+      "description": "The JSON value the function returned."
+    }
+  },
+  "type": "object"
+}

First observedOct 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructive/openWorld, and the description goes well beyond them: 330 s wall-time limit, 100 requests/minute gateway throttle with in-execution calls exempt, an explicit sandbox inventory (no host, fs, require, process, fetch), the confirmDestructive retry+reason contract, and the payment/money-movement exclusion. These are the operational facts an agent needs before invoking an arbitrary-code channel.

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?

Front-loaded with purpose, then structured into scoping, limits, a numbered discover/describe/call workflow, and result handling — easy to scan. It is long, and a few trailing items (meta.freshness, includeMetadata diagnostics, list_namespaces inventory detail) sit past the point where most agents will read, but nearly every sentence carries a distinct constraint.

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 highly complex, irreversible-feeling execution tool with an output schema, the description covers everything needed to call it correctly: sandbox boundaries, time and rate limits, discovery protocol, destructive-approval path, and both result-handle and truncation shapes. Return values are also schema-backed, so nothing material is missing.

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 description coverage is 100%, so the schema already defines both parameters in detail; the description mostly restates the 'one async arrow function' and 'JSON-serializable return' contract. It adds marginal value by naming the in-scope globals and forbidding named functions, but never explains agentSessionId semantics, so it does not exceed the baseline set by a fully documented 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?

Opens with a specific verb+resource: 'Execute JavaScript to call this app's 1265 tools across 5 namespaces,' and enumerates the namespaces with counts. This is instantly distinguishable from the shallow siblings get_info and get_profile, and an agent knows exactly what capability the tool unlocks without opening the schema.

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?

Gives an explicit workflow (search → describe → call), plus concrete when-not guidance: never sleep or poll with setTimeout, use flow.run for long work, use discover.read_result rather than returning oversized values, and never guess tool names. It also names conditional branches for authorization and destructive approvals, so almost no routing decision is left to inference.

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

All Tedix tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.