Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_installed_hdas

List installed Houdini Digital Asset definitions grouped by library file, with optional substring filters for type names or paths and a limit to control results.

Instructions

List installed HDA definitions, grouped by library file.

A stock install loads thousands; pass a filter (namespace, name or path fragment). truncated says when limit cut the list.

Args: ctx: MCP context. filter: Substring filter for type names or file paths. limit: Maximum definitions returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
filterNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changedv2.21.0
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 100,
+  "title": "Limit",
+  "type": "integer"
+}
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: results are grouped by library file, the install can be very large, and the `truncated` flag indicates `limit` cut the list. It omits auth/permission needs and any cost, but covers the key operational facts.

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 purpose and the truncation/scale caveat are front-loaded, followed by a compact Args block. The `ctx` line doesn't correspond to an actual parameter, a small bit of noise, but overall there is little waste.

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?

There is no output schema, and the description usefully explains the `truncated` signal and the grouping of results. For a simple listing tool with two optional params, this is close to sufficient; only the exact shape of returned entries is left unspecified.

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?

Schema coverage is 0%, so the description must compensate, and it does: `filter` is described as a substring match on type names or file paths, and `limit` as the maximum definitions returned. Minor gaps remain (case sensitivity, match semantics), and `ctx` is listed although it is not in the schema.

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?

The first sentence gives a specific verb and resource ('List installed HDA definitions, grouped by library file'), which is clear and distinct from siblings like get_hda_info or list_hda_versions. It doesn't explicitly contrast itself with those siblings, but the scope is unambiguous.

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?

It gives a practical hint ('A stock install loads thousands; pass a filter') that implies the intended way to use the tool, but names no alternatives and states no when-not-to-use conditions. Usage is implied rather than spelled out.

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