Skip to main content
Glama
Sign In
Houdini MCP

Houdini MCP

by beatreichenbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_sim_memory_usage

Retrieves a detailed memory breakdown for a simulation node, helping you identify memory usage and diagnose simulation performance issues.

Instructions

Get detailed memory breakdown for the simulation.

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": {
      "node_path": "<node_path>"
    },
    "name": "get_sim_memory_usage"
  }
}

Input Schema

NameRequiredDescriptionDefault
node_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. It does not say what the 'breakdown' contains, whether it is read-only or expensive, whether it requires an active sim, or what happens for an invalid node_path; only the word 'Get' hints at a read.

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

Conciseness3/5

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

A single front-loaded sentence with no wasted words, but the brevity comes from omission rather than efficiency, leaving key details unstated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and zero parameter documentation, the definition leaves the agent without enough information to call this correctly: neither the target of node_path nor the shape of the returned breakdown is known.

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

Parameters2/5

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

Schema description coverage is 0% for the single required parameter node_path, and the description adds no meaning about its format (scene path? sim node? absolute vs relative?), so the one input an agent must supply is entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Get detailed memory breakdown'), so the agent knows the general operation. However, 'the simulation' is vague: siblings include setup_flip_sim, setup_pyro_sim, setup_rbd_sim and setup_vellum_sim, yet the description never says which simulation, nor how the required node_path targets it.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of prerequisites (e.g. the sim must be set up or cooked first), and no routing to alternatives such as get_cache_status or get_context_info for related diagnostics. The agent must infer all usage context from the name alone.

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