Skip to main content
Glama
Sign In
getcustomaise

customaise

Official
by getcustomaise
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

export_script

Destructive

Export a script from a local file into Customaise. The file will be validated through Customaise's sanitization pipeline (syntax checking, AST validation, security analysis).

Instructions

Export a script from a local file into Customaise. The file will be validated through Customaise's sanitization pipeline (syntax checking, AST validation, security analysis). If valid, the script is installed and ready to execute on matching pages. If invalid, detailed diagnostics explain exactly what to fix. Pass scriptId to update an existing script instead of creating a new one. Pass expectedCodeHash from import_script to reject stale edits. Save progress includes an operation ID and stage. A timeout may leave the outcome unknown: query get_bridge_status with the scriptId and operationId from the error before retrying. The extension enforces a 90-second save deadline and cancels work that has not reached persistence. A storage write already submitted cannot be recalled; its commit receipt resolves that uncertainty. NOTE: You cannot overwrite a shared/subscribed script — they are read-only. If you need to edit a shared script, first call import_script with fork:true (creates an editable independent copy), then export to that copy's scriptId.

Reminder for new UserScripts: Prefer named functions in an IIFE for symbol-level editing; preserve valid imported source, `// @namespace https://customaise.com`, and standard directives (@name, @match, @grant).
Reminder for AgentScripts: MUST use `// ==AgentScript==` block, MUST explicitly declare tools via `// @webmcp <toolName> <permission>` (e.g. `// @webmcp my_tool prompt`). Permissions: allow (autonomous), prompt (interactive), deny (blocked). Prefer `prompt`: in a script you write, `allow` resolves as `prompt` before user grants are applied; a saved Allow rule or user-enabled Full access can permit it. Prefer named top-level functions and top-level tool registration for symbol editing; IIFEs are supported. CAN use GM_* APIs for persistence, networking, and observability alongside `navigator.modelContext.registerTool()`.

Input Schema

NameRequiredDescriptionDefault
filePathYesLocal file path containing the userscript source code
scriptIdNoID of an existing script to update. Omit to create a new script.
expectedCodeHashNoSHA-256 from import_script. Reject the save if the installed source has changed since that read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.2.3
    • addedInput schema / properties / expectedCodeHash
      Added value: +{
+  "description": "SHA-256 from import_script. Reject the save if the installed source has changed since that read.",
+  "pattern": "^[a-f0-9]{64}$",
+  "type": "string"
+}
  2. First observedv3.2.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations declare destructive and non-idempotent, and the description goes well beyond them: validation stages, the 90-second save deadline and cancellation semantics, the unknown-outcome timeout window, and the fact that a submitted storage write cannot be recalled. That is precisely the risk detail an agent needs before invoking a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core paragraph is front-loaded and dense with useful content, but the two authoring reminders for UserScripts and AgentScripts are long reference material that belongs in documentation rather than a tool definition. Several sentences (IIFE guidance, GM_* API notes) do not help an agent decide or invoke this tool.

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, non-idempotent mutation with no output schema, the description covers prerequisites, async/timeout recovery, and the read-only shared-script case. What a successful call returns is only gestured at ('operation ID and stage'), but that is a minor gap given the rest of the coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real semantics: scriptId means update-an-existing (and must target a fork if the source is shared), and expectedCodeHash must come from import_script as a concurrency guard. It stops short of adding format or failure-response detail beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific action and direction: take a local file and install it as a script in Customaise, with the sanitization pipeline spelled out. It differentiates from import_script and delete_script by describing the install/validate outcome. The only friction is the counterintuitive 'export' naming for what is effectively an import/install, which makes the agent re-read to confirm direction.

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?

Explicit branching conditions: pass scriptId to update rather than create, pass expectedCodeHash to reject stale edits, and do not attempt overwrite of shared/subscribed scripts — fork via import_script with fork:true first. It also names get_bridge_status as the recovery path after a timeout, which is exactly the alternative an agent needs.

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

Deploy Server

Other Tools