Skip to main content
Glama
Sign In
godot-omni

godot-omni

by bebabinlarsson-blip
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

pck_manage

Create, mount, and inspect Godot .pck packages to manage virtual filesystem resources dynamically.

Instructions

PCK Virtual Package Creation, Dynamic Mounting, and Inspection.

Ops:

  • create_pck(pck_path, files=[], alignment=32) Pack a list of project resource files into a standalone .pck package.

  • load_pck(pck_path, replace_files=True) Dynamically mount a .pck package into the virtual filesystem.

  • inspect_pck(pck_path) Check existence and size in bytes of a .pck package.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

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": {
      "op": "<op>"
    },
    "name": "pck_manage"
  }
}

Input Schema

NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv5.0.28

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses core behaviors: creation, dynamic mounting into the virtual filesystem, and inspection with byte size. However, it does not explain side effects of loading, whether create/load overwrite existing resources, or what happens when replace_files=True, so behavioral transparency is only partially addressed.

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?

The description is well-structured and front-loaded: a one-line title, three compact operation bullets, and a short canonical call-shape note. Each sentence earns its place, and the format is easy to scan quickly.

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?

Given the tool's three-op multiplexed nature and lack of annotations, the description covers the operations, parameters, defaults, and invocation format. It does not explain alignment, the exact meaning of replace_files, or preconditions for mounting, but since an output schema exists, the absence of return-value detail is acceptable.

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 schema has 0% description coverage, so the description must compensate. It does by providing op-specific signatures with defaults: create_pck(pck_path, files=[], alignment=32), load_pck(pck_path, replace_files=True), inspect_pck(pck_path). This gives meaningful parameter knowledge beyond the raw schema, though alignment and replace_files semantics are not explained in depth.

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?

The description opens with a precise statement: 'PCK Virtual Package Creation, Dynamic Mounting, and Inspection.' Each sub-operation has a clear verb and resource: create_pck packs files, load_pck mounts a package, inspect_pck checks existence/size. This clearly distinguishes pck_manage from domain-adjacent siblings like resource_manage or filesystem_manage.

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?

The description clearly specifies when each op is appropriate: use create_pck to pack files, load_pck to mount a package, inspect_pck to check existence and size. It does not explicitly name alternatives or state when not to use the tool, but the operation definitions give enough context for selection.

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