Skip to main content
Glama
Sign In
Houdini MCP

Houdini MCP

by beatreichenbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_installed_hdas

List installed Houdini HDA definitions grouped by library file, with optional limit and filter to find specific digital assets.

Instructions

List installed HDA definitions, grouped by library file.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_installed_hdas"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
filterNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/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 disclosure burden. It contributes one useful fact, that results are grouped by library file, but says nothing about pagination defaults, whether the listing is read-only, what happens when no HDAs are installed, or whether results are cached.

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?

A single front-loaded sentence with no redundant wording. It is efficient, though the brevity comes at the cost of the missing parameter and behavioral detail noted above.

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?

For a two-parameter listing tool with no annotations and no output schema, the description should at minimum explain filtering and paging. Those are the exact areas it omits, leaving the agent unable to predict result size or how to narrow the listing.

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%, and the description never mentions the 'limit' or 'filter' parameters. The filter's accepted syntax, matching behavior, and interaction with the 100-item default limit are all left undocumented, so the agent must guess at how to narrow results.

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

Purpose4/5

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

States a specific verb and resource ('List installed HDA definitions') plus a scope hint ('grouped by library file'), so an agent knows exactly what is returned. It does not distinguish itself from the sibling list_hda_versions, which an agent could easily confuse with this tool.

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 statement of prerequisites, and no mention of the nearby alternative list_hda_versions for version-level queries. The agent must infer from the name alone whether this is the right listing tool.

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