Skip to main content
Glama
getcustomaise

customaise

Official

import_script

Create an editable local copy of a Customaise script in your workspace. Optionally fork or duplicate the source to produce a new independent script for remixing.

Instructions

Import a Customaise script (UserScript or AgentScript) to a local file for editing. The file contains the full source with metadata block. After editing with your IDE tools, use export_script to push changes back.

Optional 'fork' flag (default false): when set to true, the script is FORKED into a new independent local copy BEFORE import, and the FORK is what gets written to the file. ALWAYS creates a new script — symmetric across source types, never a silent no-op:

  • Subscribed/shared sources: "Fork" verb. Clears the subscription link (no more publisher updates), captures forkedFrom lineage so a later publish can render "Forked from " on the marketplace.

  • Owned sources: "Duplicate" verb. Clears publishedShareId so the dup isn't tied to the original's published listing. Use when you want a remix while keeping the original intact. Forked/duplicated scripts land DISABLED in the user's library (D10 trust ceremony). The returned scriptId is the NEW script (not the original); the agent can immediately export back to it.

Without 'fork', subscribed scripts cannot be imported — they're read-only and the call refuses with a clear error pointing at fork:true. Owned scripts import normally (edit-in-place workflow).

IMPORTANT: Save files inside your current workspace or project directory (e.g., ./customaise-scripts/), never in /tmp.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forkNoWhen true, fork the script into a new editable copy and import THAT copy. Always creates a new script (Fork for shared sources, Duplicate for owned). Required for subscribed/shared scripts. Default false.
filePathYesLocal file path inside your workspace to write the script to (e.g., ./customaise-scripts/my-script.agent.js). Do NOT use /tmp.
scriptIdYesThe ID of the script to import (get from list_scripts). When fork=true, this is the source script to fork from; the returned scriptId is the new fork.
Behavior5/5

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

Beyond the annotations, it discloses that fork always creates a new script, clears subscription/publish links, lands the script disabled, and returns the new scriptId rather than the original. These are side effects an agent cannot infer from readOnlyHint=false or destructiveHint=false.

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

Conciseness5/5

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

While long, the description is organized into scannable paragraphs and bullets with no redundant filler; every block adds decision-relevant information. The critical fork behavior is front-loaded before the detail.

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 mutating tool with no output schema, it explains the key return semantics (returned scriptId is the new script), the file write target, and the error path for subscribed scripts without fork. This gives an agent enough to call and continue the edit/export workflow safely.

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?

The input schema already documents all three parameters, and the description adds meaningful operational nuance: what 'fork' means for owned vs shared sources, the lineage/publishedShareId clearing, and the D10 disabled-landing behavior. It also reinforces the filePath rule about workspace-relative paths, which is directly actionable.

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 and resource ('Import a Customaise script... to a local file for editing') and clearly identifies the output as full source with metadata block. The contrast with export_script in the first paragraph distinguishes it from the obvious sibling without ambiguity.

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?

Explicitly names export_script as the follow-up for pushing changes, and specifies the exact condition for using fork (subscribed/shared sources) plus the refusal behavior when fork is omitted. This tells an agent not just what the tool does but when it is the right call.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/getcustomaise/customaise-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server