Skip to main content
Glama
Sign In
Houdini MCP

Houdini MCP

by beatreichenbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_current_network

Navigate the network editor to a specified network path and make the viewer follow into it; optionally control other-object visibility for the target context.

Instructions

Navigate the network editor to a network; the viewer follows it in.

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": {
      "network_path": "<network_path>"
    },
    "name": "set_current_network"
  }
}

Input Schema

NameRequiredDescriptionDefault
network_pathYes
other_objectsNohide

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?

With no annotations at all, the description carries the full burden. It does disclose one side effect (the viewer follows the network), but says nothing about whether this mutates persistent state, what permissions it needs, whether it is undoable, or what happens if the path is invalid.

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 short sentence, front-loaded with the main action and effect. 'The viewer follows it in' is slightly awkward but not wasteful.

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 tool with an undocumented enum-less parameter and zero annotation or output-schema support, one sentence is not enough. The agent still cannot confidently supply 'other_objects' or predict the result of an invalid network path.

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%, so the description must compensate, and it does not. It vaguely implies network_path refers to a target network but gives no path syntax or format, and the second parameter 'other_objects' (default 'hide', nullable, no enum) is never mentioned at all.

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: navigating the network editor to a given network, plus the side effect that the viewer follows. That is concrete enough to distinguish it from siblings like build_network or get_network_overview, though it never names an alternative to contrast against.

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?

No when-to-use or when-not-to-use guidance, no prerequisites, and no mention of how this relates to set_current_take or the other set_* context tools. The agent must infer that this establishes editing context for subsequent operations.

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