Telerivet

run_script

Destructive

Run JavaScript with full Cloud Script API access (reads, writes, sending, HTTP requests) — use this for bulk changes that would otherwise take many individual API calls, such as importing or cleaning up many records. Write the code exactly as described for run_analysis_script (same sandbox, limits, and documentation references). Use batch methods (e.g. importContacts) when available. Can make HTTP requests, e.g. to import or export data without passing it through model context. This tool makes changes with the user's full API access: show the user the code and what it will do before calling, and keep it short, readable, and single-purpose. Prefer run_analysis_script for anything that doesn't change data.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "run_script"
  }
}

Input Schema

Name	Required	Description
`code`	Yes	JavaScript code to execute (Cloud Script API, full access)
`summary`	No	One-sentence plain-language summary of what this script is intended to do, shown to the user in the confirmation prompt alongside the code (always provide this)
`project_id`	No	ID of the project to run the script in (call API_queryProjects to look up a project ID if you don't already have one). Optional: omit it to run in organization-only context — the `project` global is then undefined, while the `organization` global is still available (e.g. for billing or usage questions).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the destructive/openWorld annotations it discloses that the script executes under the user's full API access, that HTTP requests can move data without passing through model context, and imposes a pre-call obligation to show the user the code first. It also constrains authoring style (short, readable, single-purpose), which the agent cannot infer from annotations alone.

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 usage, then safety preconditions in a sensible order. Minor redundancy: HTTP access is mentioned twice (first sentence and again with the import/export rationale), though the second mention does add the context-bypass reason.

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?

For a destructive, open-world code-execution tool with no output schema, the definition covers purpose, alternatives, authorization scope, and pre-call confirmation. It does not say what the script returns or how results/errors surface, which is the main remaining gap.

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 code, summary, and project_id are already fully documented, including the organization-only fallback behavior. The description adds no parameter-level detail beyond a cross-reference to run_analysis_script's writing conventions, so the baseline of 3 applies.

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?

States a specific verb and resource ('Run JavaScript with full Cloud Script API access') and scopes it to bulk mutations that would take many individual API calls. It explicitly separates itself from the sibling run_analysis_script, so an agent can pick correctly without opening either 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 concrete when-to-use guidance (bulk importing or cleaning up many records), a when-not alternative ('Prefer run_analysis_script for anything that doesn't change data'), and an implementation hint to use batch methods like importContacts when available.

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

All Telerivet tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?