Skip to main content
Glama

Api Manage

api_manage

Inspect Godot editor ClassDB metadata to get properties, methods, signals, enums, constants, and defaults for any class without instancing it. Retrieve only the sections you need, with pagination.

Instructions

Inspect Godot API documentation-shaped metadata from the connected editor's ClassDB: "what properties does X have", method signatures, signals, enums, constants, defaults, and property hint strings.

Resource form (prefer for active-session reads): godot://class/{class_name}

Ops:

  • get_class(class_name, sections=None, include_inherited=False, include_inheritors=False, offset=0, limit=100) Return selected class-reference sections without creating a scene instance. sections may be a comma-separated string or list containing properties, methods, signals, enums, constants, inheritors. Defaults to ["properties"] only — a bare get_class answers "what properties does X have" without the multi-thousand-token full dump. Pass the sections you want by name, or "all" for the full set (properties, methods, signals, enums, constants). "all" does NOT include the heavier "inheritors" section — request that by name. For pagination, request one section at a time so offset/limit apply only to the list you are paging.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.9.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it states the call returns class-reference sections without creating a scene instance, notes that 'all' excludes the heavier inheritors section, and explains default section behavior and one-section-at-a-time pagination. It could still be more explicit about the operation being read-only and side-effect free, but these traits are strongly implied and the disclosure is substantive.

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?

The description is longer than average and dense, but it is organized with a purpose statement, resource form, op signature, and transport notes. A little tightening is possible (for example the canonical call shape could be moved earlier), yet every substantive detail serves the zero-coverage schema.

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 sparse schema and no annotations, the description provides the needed operational context: op name, params object contents, defaults, pagination, and call-shape conventions. An output schema exists, so return values need not be described; remaining gaps like explicit include_inherited/include_inheritors semantics or required session_id are minor.

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

Parameters5/5

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

Schema description coverage is 0%, so the description is the only source of parameter meaning, and it compensates thoroughly. It documents the get_class signature with defaults, explains the allowed sections values, clarifies the 'all' special value, and gives pagination guidance; it also clarifies op, params, and session_id placement and the compatibility alias.

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 specific verb and resource: it inspects Godot API documentation-shaped metadata from the editor's ClassDB, and lists concrete question types (properties, method signatures, signals, enums, constants, defaults, hint strings). It also names the single supported op, get_class, which makes the tool distinguishable from the surrounding node/project/scene management siblings.

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

Usage Guidelines3/5

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

There is some internal guidance: the resource form is preferred for active-session reads, and the flat-parameter form is described as a compatibility alias. However, the description never says when to choose api_manage over sibling tools such as node_get_properties, nor does it state explicitly when not to use this tool; usage context is implied rather than contrasted.

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