Skip to main content
Glama
bacarrdy

VPSnet

by bacarrdy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update function

update_function
Destructive

Update a VPSnet Firecracker Function's code or configuration by replacing provided fields, including runtime, resources, environment, and webhook settings; call get_function first.

Instructions

Update a Firecracker Function's code or configuration. This replaces submitted fields and can change or disable a public webhook. Call get_function first. If integrity.unreadable_fields names code or environment, the backend refuses the update unless the user explicitly approves replacing every unavailable value from a trusted copy and acknowledge_unreadable_replacement=true is passed. Leave that flag false for ordinary updates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoFunction source code
nameNoFunction name
vcpusNo1-8 vCPUs, default 1
enabledNoWhether the function can be invoked
memory_mbNo64-8192 MB, default 256
entrypointNoEntrypoint command/handler
descriptionNoDescription (max 2000 chars)
environmentNoEnvironment variables as JSON object string. Omit during unrelated edits to preserve existing values; never send back redacted placeholders.
function_idYesFunction ID from list_functions
runtime_os_idNoRuntime OS ID (see list_functions response for available runtimes)
timeout_secondsNo1-300 seconds, default 30
webhook_enabledNoExpose a public webhook URL for this function
private_network_idNoPrivate network ID from list_functions privateNetworking discovery. Omit to preserve an existing binding during update; null detaches it. Backend validates ownership and availability.
rotate_webhook_secretNoRotate the webhook secret
acknowledge_unreadable_replacementNoExplicit customer approval to replace code or environment named by integrity.unreadable_fields; default false

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.16

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds significant operational context: it replaces submitted fields, can disable a public webhook, and describes the backend's refusal behavior around unreadable fields. It stops short of describing rate limits or return values.

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?

Four tight sentences front-loading the core purpose, then prerequisites, then the conditional integrity workflow. Every sentence carries operational weight without padding.

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 15-parameter destructive mutation tool with no output schema, the description covers the essential workflow (get_function first), the destructive side effect (webhook changes), and the critical conditional flag. Given the rich schema, this is complete enough for correct invocation.

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 documents all 15 parameters thoroughly. The description emphasizes the critical acknowledge_unreadable_replacement flag and webhook implications, but adds little syntax beyond what the schema provides for other params.

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 ('Update a Firecracker Function's code or configuration') and names the exact scope of changeable fields. It is clearly distinguishable from sibling tools like create_function or delete_function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Call get_function first' and routes the agent through the integrity.unreadable_fields workflow. It states when to set acknowledge_unreadable_replacement=true vs leaving it false, though it doesn't broadly compare to other update tools.

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