Skip to main content
CodeCall configuration options CodeCall configuration options This page covers all configuration options for the CodeCall plugin, from quick presets to fine-grained control.

Plugin Initialization

plugins: [CodeCallPlugin], the class without init(), is the same as CodeCallPlugin.init(): the defaults below, with the six codecall:* meta-tools and CodeCallConfig. Up to 1.9.3 the class form installed no tools (1.9.2: the tools without CodeCallConfig), while codecall_only still hid the app’s own tools, so tools/list was empty.

Tool Visibility Modes

Control which tools appear in list_tools vs. CodeCall. Default mode. Hides all tools from list_tools, exposes via CodeCall.
Best for: Large toolsets (20+), OpenAPI adapters, clean client experience.
A tool CodeCall hides from list_tools is reachable only through CodeCall, in every mode: a client’s direct tools/call of it is answered exactly like a call of an unknown tool (Tool "<name>" not found), before its input is validated, so the refusal reveals nothing about it. CodeCall’s own calls (codecall:execute, codecall:invoke) and server-side composition (a tool, agent or job calling it with this.callTool()) still reach it, and the server’s own system tools (such as sendElicitationResult) are never refused. A visibility: 'hidden' tool, which the SDK keeps out of list_tools, is refused the same way in every mode unless it sets visibleInListTools: true (up to 1.9.1 a client could call it directly in codecall_opt_in and metadata_driven, and in codecall_opt_in visibleInListTools: false hid nothing). Releases up to 1.8.7 hid the tool from the listing only, so a client that knew its name called it directly, past includeTools, enabledInCodeCall, the blocked namespaces and directCalls. A tool that clients or widgets must call directly sets visibleInListTools: true.
Installed on an app, CodeCallPlugin judges that app’s tools and those of apps without a CodeCall plugin of their own; installed on the server, it judges every tool. A tool is hidden from list_tools and refused on a direct tools/call by the same plugins, so with a CodeCall plugin on each of two apps, each app’s tools are listed and called by its own plugin’s mode. Releases up to 1.8.7 let one app’s codecall_only plugin hide the other app’s tools from list_tools while the other app’s plugin still let clients call them directly.

codecall_opt_in

Tools must explicitly opt into CodeCall. All tools visible in list_tools by default.
Best for: Gradual migration, mixed direct/CodeCall access.

metadata_driven

Full control via per-tool metadata. No global assumptions.
Best for: Small toolsets, fine-grained control.

Per-Tool Metadata

Control individual tool behavior with the codecall metadata field:

Metadata by Mode

Common Patterns

Use for: Most tools in codecall_only mode. A client’s direct tools/call of the tool is refused as for an unknown tool; it is reached through CodeCall.
Use for: Core tools that should be directly accessible AND in CodeCall.
Use for: Admin tools, destructive operations, tools requiring human review.
Applied automatically to codecall:search, codecall:describe, etc.

Global Tool Filtering

Filter tools globally with includeTools:
The filter receives an IncludeToolsFilterToolInfo:
So a filter can decide from the tool’s annotations, e.g. includeTools: (tool) => !tool.annotations?.destructiveHint (tool.metadata?.annotations is the same object). directCalls.filter receives the same object. name is the name the tool was declared with. A tool admin:deleteUser in app crm is also reachable as crm:admin:deleteUser, but the filter always sees admin:deleteUser; use appId to filter by app. The filter is an access control, not only a search setting. CodeCall runs the same decision, with the same tool object, for codecall:search, codecall:describe, callTool and getTool in codecall:execute, the namespace bindings a script receives, and codecall:invoke. A tool the filter excludes is absent from search, reported as not found by describe, and refused at execution.

VM Configuration

Configure the JavaScript sandbox:

VM Presets

allowLoops: false refuses every loop but for-of before the script runs; allowLoops: true adds for. The sandbox refuses while, do-while and for-in whatever allowLoops says. Scripts have no console in any preset, so allowConsole has no effect: a script that refers to the global console is refused before it runs (a field named console, as in result.platform.console, is fine), and mcpLog(level, message) is the way to log. The codecall:execute description is written from the effective vm options: the loops allowLoops permits, the names disabledBuiltins and disabledGlobals list, timeoutMs and the tool-call cap (maxSteps), so a model’s scripts run on every preset. codecall:search’s description gives the server’s topK and the minRelevanceScore default, 0.1. Up to 1.9.1 allowLoops: false let a for loop run, and up to 1.9.2 the descriptions named fixed limits (a 30 s timeout, 100 tool calls, a 0.3 threshold) whatever the configuration said. disabledBuiltins and disabledGlobals name globals a script may not use: a script that refers to one is refused before it runs, with illegal_access and JSON is disabled by vm.disabledGlobals (a field or key with that name, as in formats.JSON, is fine). They add to what the sandbox already refuses: AgentScript never gets eval, require, process or fetch, so leaving one out of the list doesn’t allow it. Up to 1.9.2 both lists were accepted and ignored. A loop that runs more than 10,000 times ends the script with runtime_error, Maximum iteration limit exceeded (10000). This limit prevents infinite loops., whatever the loop; up to 1.9.2 a for loop gave a different message, without the count, and the error name DoubleVMExecutionError.
allowConsole stays deprecated: the sandbox (@enclave-vm/core) writes a script’s console output to the server’s own stdout, which would corrupt a stdio transport, and offers no way to capture it.

Preset Details

When to use: Healthcare, finance, PII processing, compliance-heavy environments.

Reference Sidecar Configuration (Pass-by-Reference)

The Reference Sidecar handles large data transfer between scripts and tools. Instead of passing full data through the VM, large values are stored externally with reference IDs.

Sidecar Presets by Security Level

How Pass-by-Reference Works

Benefits:
  • Scripts don’t need to handle large data in memory
  • VM stays lightweight and secure
  • Tool results can exceed VM memory limits
  • Reference IDs are opaque strings (no data leakage)

Embedding Configuration

Configure how tools are indexed for search:

Strategy Comparison

TF-IDF Configuration

TF-IDF extracts searchable text from:
  • Tool name (tokenized: users:list → users, list)
  • Description (weighted 3x)
  • Key terms from description (4+ characters, no stop words)

ML Configuration

ML strategy uses VectoriaDB internally. The model (~22MB) is downloaded on first use and cached locally.

Direct Invocation

Configure the codecall:invoke meta-tool for direct tool calls without VM overhead:
Each allowedTools entry matches a tool’s own name (users:getById) or its qualified <appId>:<name> (my-app:users:getById). List the qualified name to allow the tool from one app only; a bare name allows that tool in every app that declares it. Anything not listed is refused. allowedTools and filter only narrow what the base policy (enabledInCodeCall, includeTools, the blocked namespaces) already allows; listing a tool the base policy withholds does not make it callable. filter receives the same object as includeTools.

When to Use Direct Invoke

Performance Comparison

Error Response Format

A refused call returns a standard CallToolResult. The message is the same whether the tool is withheld or does not exist, so codecall:invoke does not reveal which tools the policy hides:

Security Considerations

Direct invocation bypasses VM security validation. Only enable for tools you trust completely.
  • allowedTools: Always specify an explicit allowlist in production
  • No script execution: Direct calls cannot run arbitrary code
  • Same tool access rules: codecall:invoke first applies the policy codecall:execute uses (enabledInCodeCall, includeTools, blocked namespaces); directCalls only narrows it
  • Audit logging: Direct calls are logged the same as scripted calls

Complete Configuration Example


Migration Guide

From Direct Tools to CodeCall

1

Add CodeCallPlugin

2

Mark Tools for CodeCall

3

Test Both Access Methods

Verify tools work via both direct calls and CodeCall.
4

Switch to codecall_only

From here a client’s direct tools/call of a hidden tool is refused. Keep visibleInListTools: true on any tool a client or widget still calls directly.
5

Remove Direct Visibility


Security Model

Security implications of configuration choices

Production & Scaling

Performance tuning and monitoring

AgentScript Guide

Scripting language reference and best practices

API Reference

Complete meta-tool schemas and examples