Skip to main content
Glama
naotochan

polynodes-osc-mcp

by naotochan

polynodes_gain_solo

Idempotent

Solo or unsolo a specific PolyNodes layer by sending macro, meso, or micro level with state 1.0 or 0.0. Returns JSON confirmation.

Instructions

Solo a specific layer (macro/meso/micro).

Args: params: level and state (1.0=solo, 0.0=unsolo).

Returns: JSON confirmation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which correctly frames this as a safe, repeatable state setter. The description adds the binary state semantics and the fact that it returns a JSON confirmation, but does not say whether soloing one layer unsolos others or how it interacts with overall gain.

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?

Front-loaded action statement followed by a compact Args block and a one-line Returns note. Every line earns its place with no filler, though the Args block largely duplicates the 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?

For a simple binary-state setter whose annotations cover the safety profile and whose output schema covers the return value, the description is nearly sufficient. The only unaddressed behavior is the side effect on other layers when soloing.

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

Parameters3/5

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

Top-level schema coverage is 0% for the single 'params' object, but the nested properties are already fully documented in the schema ('macro', 'meso', or 'micro'; 0.0 = off, 1.0 = solo). The description restates level and state but adds no meaning beyond those nested descriptions, so it neither fully compensates nor adds value.

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 description states a specific verb (solo) and resource (a specific layer, scoped as macro/meso/micro), which is enough to tell it apart from the many switch/set siblings. It is clear but does not explicitly contrast itself with close relatives like polynodes_set_gain.

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?

Usage is implied by the argument semantics (1.0=solo, 0.0=unsolo), so an agent can infer that this sets a binary solo state per layer. However, there is no explicit when-to-use guidance, no statement of when to prefer this over polynodes_set_gain, and no exclusions.

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