PureData-MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation4/5
Most tools target distinct actions (create, attach, stop, status), but pd_set_params and pd_send_control overlap in sending control messages, and the three start-related tools (pd_start_demo, pd_start_live_session, pd_open_patch) could be confused. Descriptions help disambiguate, but a few boundaries remain fuzzy.
Naming Consistency4/5
The naming pattern is largely pd_verb_noun, with a consistent pd_live_ prefix for canvas editing operations. However, a few tools like pd_status and pd_live_graph use nouns instead of verbs, breaking the otherwise predictable convention.
Tool Count3/5
With 21 tools, this sits in the heavy range (16-25) for a well-scoped MCP server. The breadth of Pure Data lifecycle and live-editing operations justifies many tools, but some could be consolidated (e.g., pd_start_demo and pd_start_live_session overlap).
Completeness4/5
The tool surface covers the full patch lifecycle (create, open, launch, preview, save, stop) plus detailed live canvas editing and parameter control. Minor gaps include no explicit DSP toggle and limited audio device configuration, but core workflows are well supported.
Average 3.4/5 across 21 of 21 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'update' implying mutation and 'running' implying a required state, but it does not explain side effects, parameter constraints, error behavior, or whether changes are reversible. The word 'bounded' suggests internal limits but they are not clarified.
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?
The description is a single concise sentence that gets to the point, which is positive. However, it lacks any structural elements like examples, expected input formats, or additional context that would make it genuinely helpful. It is short but not effectively structured for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameters, the description is far from complete. It does not explain how the tool behaves in typical use cases, what the agent should expect as a result, or how to provide any input. This is a critical deficiency for a tool whose core purpose requires parameter specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, yet the tool's purpose is to set parameters, creating a glaring gap. The description does not explain how parameters are specified, what those parameters are, or how the tool identifies which parameters to update. With 0 parameters in the schema and no clarification in the description, the agent cannot properly invoke this tool.
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 clearly states a verb ('update') and a resource ('bounded live parameters on the running Pd demo patch'), making the core action understandable. However, the term 'bounded' is ambiguous and the description does not differentiate this tool from siblings like pd_send_control or pd_live_update_object, which could also update parameters.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., a running patch), limitations, or scenarios where other tools are more appropriate. The only implicit context is 'running' which hints at a prerequisite but is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'rebuilding the visible MCP live canvas,' which hints at a potentially broad side effect, but it does not clarify whether this is destructive, whether a live session is required, or how it affects connected objects. This is insufficient for a mutation-like operation.
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 description is a single sentence, front-loaded with the main action, and contains no filler words. It efficiently states the purpose and a key implementation detail, though it could be improved by adding usage guidance without much extra length.
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?
Given the absence of annotations and an output schema, and the potentially impactful side effect of rebuilding the canvas, the description is incomplete. It lacks information on preconditions (e.g., active live session), return values, error behavior, and the scope of the rebuild, making it hard for an agent to anticipate the consequences of invocation.
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 does not explain the parameters explicitly. While id, x, and y are somewhat self-explanatory and the schema provides constraints, the description does not clarify units, coordinate origin, or the meaning of 'agent-created' in relation to id. It only vaguely references 'new coordinates.'
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 clearly states the tool moves an agent-created live object, using the specific verb 'move' and naming the resource ('agent-created live object'). It also specifies the mechanism ('by rebuilding the visible MCP live canvas'), but it does not explicitly differentiate from sibling tools like pd_live_update_object, which could also reposition objects.
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 explicit guidance on when to use this tool compared to alternatives is provided. The phrase 'agent-created live object' implies a restriction, but there is no mention of when to choose this over pd_live_update_object or other sibling tools, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects but only states the resulting state (visible, empty, agent-managed). It does not mention overwrite behavior, impact on existing sessions, audio output configuration, or whether it stops other sessions, leaving significant behavioral uncertainty.
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 description is a single sentence that front-loads the verb and concisely conveys key details. It is efficiently structured without unnecessary words, though it uses domain jargon that could be clearer.
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?
The tool has 5 optional parameters, no annotations, and no output schema, so the description alone must provide complete context. It covers the high-level purpose but leaves parameter semantics and differentiation from siblings unaddressed, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description provides no explanation of dsp, gui, overwrite, targetPath, or audioOutDevice. The agent cannot infer parameter meanings or defaults beyond raw types and defaults.
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 clearly states the action ('Create and launch') and the resource ('visible live-edit Pd patch'), with specific scope ('empty agent-managed canvas ready for pd_live_replace_graph'). It is distinct from generic create tools, but does not explicitly differentiate from sibling pd_create_live_patch.
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?
The description implies this is the first step in a live-edit workflow, especially 'ready for pd_live_replace_graph', but it provides no explicit when-to-use guidance or alternatives. It does not mention when to prefer pd_create_live_patch or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral consequences, but it only states the action ('Silence and stop'). It does not mention side effects such as losing unsaved changes, terminating a live session, or the effect of the 'force' parameter. This is insufficient for a process-terminating tool.
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 description is a single, concise sentence with no wasted words. It is front-loaded with the verb and resource. While it could include more details, it is appropriately sized for a simple operation.
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?
The tool is simple, but the description omits the meaning of the 'force' parameter and does not explain the effect on related live sessions (e.g., pd_start_live_session). Without annotations, these missing details leave the description incomplete for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'force' with 0% schema description coverage, and the tool description does not mention it at all. The agent is left to guess what 'force' does (e.g., force kill vs. graceful stop), which is a critical gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('stop') and resource ('currently running Pd process'). It distinguishes from sibling tools like pd_start_live_session or pd_open_patch, as none of them are about stopping the process.
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: the tool should be used when the user wants to stop the currently running Pd process. However, the description does not provide explicit context about when to use it versus alternatives (e.g., pausing or sending control signals) or any when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that the tool 'returns' the graph, implying a read-only operation, but it doesn't describe prerequisites, error behavior, or what 'agent-managed' entails. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the tool's function without any redundancy or extra fluff. It is appropriately front-loaded and concise for a tool with no parameters.
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?
While the tool is simple, the description is minimal and leaves out important context such as whether an active live session is required, what the returned graph structure looks like, and how this tool fits into the broader workflow. Since there is no output schema, the description should at least hint at the return value's nature, but it only says 'object and connection graph'.
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?
The tool has zero parameters, and the input schema is empty, so schema coverage is trivially 100%. The description needs to add no parameter information, and the baseline of 4 is appropriate for this no-parameter scenario.
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 uses a specific verb 'Return' and identifies the resource as the agent-managed live patch object and connection graph, which clearly indicates a read-only inspection tool. However, it does not explicitly differentiate itself from sibling tools like pd_status or pd_live_replace_graph, though the focus on returning the graph is fairly specific.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used to inspect the current live graph, nor does it indicate any prerequisites such as an active live session, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions one extra detail (that the live canvas is included) but omits critical mutation behaviors: what happens if the target file exists and overwrite is false, whether the file is created if absent, error/return behavior, and permissions. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core action. Every phrase earns its place, including the parenthetical 'including the live canvas' which adds useful context without verbosity.
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?
A mutation tool with no annotations, no output schema, and two parameters should provide more guidance. The description assumes context from related live-session tools (e.g., what 'active patch file' means) and does not explain the overwrite behavior or success/error outcomes. It is minimally viable but leaves clear gaps for an agent to misuse.
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 explain the parameters. It clarifies that `targetPath` is an absolute path, adding some meaning beyond the schema. However, `overwrite` is not mentioned at all; its default of `false` and effects (e.g., does it fail or auto-rename?) are unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes/saves the current Pd patch to a file, specifying both the source ('current generated Pd patch, including the live canvas') and destination ('active patch file or an absolute targetPath'). It distinguishes itself from sibling tools like pd_create_live_patch or pd_preview_patch by being the persistence operation.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The only usage signal is implicit: use it to save a patch. There is no explicit mention of when to choose this over preview or open, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that patchPath is optionally loaded for preview and save, and that attachment is via control/edit ports. But it omits side effects, failure modes, or state changes beyond attachment.
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 sentence that conveys the core function and optional behavior. It is slightly dense but not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential action and parameter roles for a 3-param tool, but omits usage guidance, side effects, and return information. Given no output schema and no annotations, more context would be expected.
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 has 0% description coverage, so the description must and does explain parameter meaning: control and edit ports are the connection endpoints, and patchPath is the optional patch to load for preview/save. It does not detail constraints, but maps all three parameters.
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 clearly states the tool attaches to an already-open MCP live-edit Pd patch, specifying the resource and action. It distinguishes from starting a new session by the phrase 'already-open', though it does not explicitly name sibling alternatives.
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?
The phrase 'already-open' implies usage when a live-edit session exists, providing some context. However, it does not explicitly state when not to use it or mention alternatives like pd_start_live_session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does reveal that this is a destructive 'replace' of the existing graph and that it affects the visible GUI. Yet it does not mention whether it stops audio, resets state, or the safety mechanisms behind 'safe precomposed graph', leaving gaps.
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 description is a single, front-loaded sentence that efficiently communicates the core action and outcome. It includes a slight redundancy ('Preferred live composition path') but otherwise contains no wasted words.
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?
This is a complex tool with nested object parameters, no output schema, and no annotations. The description provides minimal context about return values, error conditions, prerequisites, or side effects beyond the basic replace-and-render behavior, making it inadequate for an agent to use confidently.
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 coverage is 0% and the description makes no explicit mention of the 'nodes' and 'connections' parameters. The term 'graph' implies these structures but provides no detail on their purpose, format, or constraints, forcing the agent to rely solely on the inline 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 description uses a specific verb ('replace') and resource ('agent-managed live graph'), and explicitly mentions rendering to the GUI canvas. It distinguishes itself from sibling tools by indicating this is the 'preferred live composition path' and replaces the entire graph, unlike incremental tools like pd_live_add_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly positions itself as the preferred path for live composition, giving strong contextual guidance. However, it does not explicitly mention when not to use it or name alternative tools for smaller changes, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It claims the message is 'safe' and that it works 'without rebuilding the canvas,' but it doesn't explain what 'safe' means, whether it can crash the patch, what happens with invalid messages, or any side effects on the running state. This is a significant gap for a tool sending raw control messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence starting with the core verb 'Send' and resource. Every word adds value, with no filler or repetition. It is appropriately front-loaded and concise.
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?
Given the simple schema but no annotations and no output schema, the description needs to provide enough context for an agent to invoke the tool correctly. It omits parameter semantics, error handling, and clear differentiation from pd_set_params, leaving the agent under-informed for a tool that sends raw messages to a live patch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of 'selector' or 'args.' The agent must infer that 'selector' is the message name and 'args' its arguments, but no semantics or format hints are provided. The description completely fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'Send' and a specific resource: 'safe raw control message' to the 'running live patch control bus' for 'parameter tweaks without rebuilding the canvas.' This distinguishes it from higher-level siblings like pd_set_params, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'for parameter tweaks without rebuilding the canvas' implies this is for fine-tuning a running patch rather than structural edits. However, it doesn't explicitly name alternatives or state when not to use the tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions 'Remove' and 'rebuild canvas' but does not state that the operation is destructive/irreversible, what permissions are needed, or what happens if the object does not exist. The lack of safety context is significant for a removal tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently structured sentence. It front-loads the action, specifies the resource, and states the consequence without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one parameter, and the description covers the core behavior and the rebuild side effect. However, it lacks information about return values, error behavior, and the practical implications of 'rebuild the visible MCP live canvas'. Given no output schema and no annotations, some gaps remain.
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?
The description does not mention the 'id' parameter at all, and schema coverage is 0%. The only hint is 'agent-created live object', which indirectly suggests the id refers to the object, but the description does not explain how to supply the id or any additional meaning beyond the schema's pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove', the resource 'live object', and the scope 'agent-created'. It also identifies the side effect of removing incident connections and rebuilding the canvas, which distinguishes it from sibling tools like add, update, or connect.
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?
The description implies usage by stating it removes an agent-created live object, but it does not explicitly mention when to use this tool versus alternatives such as pd_live_clear or pd_live_disconnect. There are no clear exclusions or alternative recommendations, only an implied condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral transparency burden. It does disclose that the tool only operates on 'agent-created' objects and that it 'rebuilds the visible MCP live canvas' as a side effect, which is useful context. However, it does not mention mutability, reversibility, permission requirements, or what happens to unspecified fields, making it only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that starts with the action verb and packs the core information—resource, fields, and side effect—without any wordiness. It is front-loaded and every phrase earns its place.
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?
Given the empty input schema and lack of annotations or output schema, the tool is under-specified. The description reveals the types of changes but omits essential details such as how to specify the object, how parameters are passed, and what the tool returns. This leaves the agent unable to invoke it correctly without additional information.
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?
With zero parameters in the schema, the description must compensate, and it does mention the updatable fields (type, arguments, coordinates). Yet it fails to specify how to identify the target object or provide any syntax for these updates. The baseline for 0 params is 4, but the description only partially fulfills the need, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update' as the verb, clearly identifies the resource as an 'agent-created live object', and specifies the fields affected (type, arguments, or coordinates). It also notes the consequential rebuild of the visible MCP live canvas, which differentiates it from related tools like pd_live_move_object or pd_set_params.
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 explicit guidance on when to use this tool versus alternatives such as pd_live_move_object or pd_set_params. The description implies usage for updating object attributes but does not provide exclusions, prerequisites, or comparisons with sibling tools, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors such as headless launch, DSP start, and FUDI control preparation, but omits side effects like overwriting files or audio output behavior, leaving gaps in transparency.
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 description is a single sentence that efficiently lists five actions without fluff. It could be structured more clearly by separating the launch and configuration aspects, but it remains appropriately sized and front-loaded.
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 7 parameters, no annotations, and no output schema, the description is incomplete. It does not explain parameter ranges, overwrite semantics, patch choices, or what the tool returns. It leaves significant gaps in context that an agent would need to operate correctly.
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 coverage is 0%, and the description only adds context for gui (explaining the headless default) and targetPath (mentioning it can be absolute). Parameters like amplitude, frequency, patch, overwrite, and audioOutDevice remain unexplained, so the description insufficiently compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb sequence: generate a demo patch, launch Pd, start DSP, and prepare FUDI control. It distinguishes itself from sibling tools by focusing on demo patch generation rather than live sessions or opening existing patches.
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?
The description implies usage for creating and starting a demo patch, but does not explicitly contrast with alternatives like pd_start_live_session or pd_open_patch. No when-not-to-use guidance is given, so it earns a middle score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It only mentions 'safe-palette' and 'visible canvas,' but does not explain side effects, constraints on existing objects, what happens when called outside a live session, or response/error behavior. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly-worded sentences with no fluff. The first sentence states purpose, the second supplies usage boundaries. Very efficient.
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?
While the usage contrast with pd_live_replace_graph is valuable, the description omits essential details: parameter meanings, coordinate system, prerequisites (e.g., active live canvas), and return value. With no annotations or output schema, this is incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter. It fails to clarify that 'x' and 'y' are canvas coordinates, or that 'args' holds arguments for the object. The agent is left to infer semantics from the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Add one safe-palette object to the visible MCP live canvas'), clearly stating verb, resource, and scope. It also distinguishes from the primary alternative by mentioning pd_live_replace_graph for complete patches, which helps disambiguate among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use only for tiny follow-up edits,' and when not to: 'for complete musical patches, generate a full graph and call pd_live_replace_graph once.' This is direct guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states a destructive action ('Clear') and an id reset, but it does not disclose potential side effects (e.g., losing all objects and connections, irreversibility) or whether it affects the live session state. Given the lack of annotation protection, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It effectively communicates the action and its effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters and no output schema, so the description is mostly sufficient. However, it lacks behavioral context around what 'clear' means for existing objects and connections, and whether the action is reversible, which is expected for a destructive tool under the no-annotations condition.
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?
The tool has zero parameters, so the schema already fully covers parameter semantics. The description adds no parameter details, but with zero params the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clear') and identifies the exact resource ('agent-managed MCP live canvas') plus the effect ('reset its object ids'), clearly distinguishing it from sibling tools like pd_live_remove_object or pd_live_replace_graph.
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?
The description implies usage (use when you need to clear the canvas), but it never explicitly states when to use this tool versus alternatives like removing individual objects or replacing the graph. No exclusions or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the patch becomes the MCP-managed process and lists supported operations, which adds context beyond the schema. But it omits side effects such as whether an existing process is replaced, blocking behavior, or error handling, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb and key resource. It is concise and every word earns its place.
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?
The tool has 3 parameters, no output schema, and no annotations. The description explains the main purpose but not return values, errors, process lifecycle, or how it interacts with already-running sessions. This leaves significant operational gaps, especially given the richness of the sibling tool set.
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. It adds meaning to patchPath by specifying 'absolute .pd' path, but it does not explain gui or audioOutDevice. Since two of three parameters remain undocumented, the description only partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Launch' and names the resource 'existing absolute .pd patch path', clarifying it becomes the MCP-managed process for status, preview, save, and stop. This clearly distinguishes it from siblings like pd_create_live_patch or pd_start_live_session that create or start without opening an existing file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to open an existing patch as the central MCP-managed process before performing status, preview, save, or stop operations. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the query is 'best-effort' and depends on a 'configured Pd binary', which hints at potential failure or configuration requirements. However, it does not explain what happens on failure, what exactly is returned, or any side effects. With no annotations, some transparency is present but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('Best-effort query'). No unnecessary words or repetition, making it highly efficient.
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?
The tool is simple with no parameters and no output schema. The description adequately conveys the purpose and the best-effort nature, though it could mention the expected return format or error behavior. Given the low complexity, the description is nearly complete.
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?
The tool has zero parameters, and the schema is empty with 100% description coverage. Since there are no parameters to document, the description need not explain any parameter semantics, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a query of Pd audio devices using the configured Pd binary. The verb 'query' and the resource 'Pd audio devices' make the purpose unmistakable, and it is distinct from sibling tools that handle patches and sessions.
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 guidance is provided on when to use this tool versus alternatives. While the siblings are clearly different actions, the description does not mention specific scenarios, prerequisites, or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately lists the output categories, but does not explicitly state that the operation is read-only, nor does it mention prerequisites like an active session or potential error conditions. 'Return' implies non-mutating, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear verb and no redundant words. It is appropriately concise for a zero-parameter tool.
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?
The description covers the key output areas and is sufficient for a tool with no parameters and no output schema. However, it lacks detail on the return format or preconditions, leaving minor gaps for an agent that needs to interpret the result.
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?
The tool has zero parameters, so the schema coverage is 100% vacuously. Per the guidelines, a baseline of 4 is appropriate because there is no parameter detail to explain, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and clearly identifies the resource as 'Pd lifecycle state, patch path, parameters, and recent errors'. This distinguishes it from sibling tools that create, modify, or start sessions, making the tool's purpose unambiguous.
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?
The description does not provide any when-to-use or when-not-to-use guidance, nor does it mention alternatives. It simply states the tool's action without contextualizing when it should be called relative to other pd_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly discloses the primary side effect of writing a file and its workflow purpose. It does not mention behavior around overwriting existing files, dsp defaults, or potential errors, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and provides essential purpose and workflow context with no filler. Every word contributes to understanding.
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?
Given it is a simple file-creation tool without an output schema, the description sufficiently explains what is created, why, and the follow-up workflow. It leaves some parameter details to the schema and does not mention return values, but these are not critical for this tool's primary use.
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?
Schema description coverage is 0%, but the phrase 'control/edit ports' adds meaning to controlPort and editPort, and 'write a .pd file' implies targetPath. It does not explain dsp or overwrite, so compensation is partial but meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Write' with resource '.pd file' and clearly explains the unique purpose: a live-edit bridge with known control/edit ports for later attachment by Codex. This distinguishes it from siblings like pd_attach_live_session, pd_open_patch, and pd_save_patch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use: creating the bridge file so the user can open it manually and Codex can attach later. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful constraints (short list, blocked connection type) but does not disclose side effects such as whether existing connections are replaced, whether the operation is reversible, required permissions, or what the response looks like. It is above the bare minimum but lacks substantive behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place. The core action is upfront, the usage caveat is second, and the critical limitation is last. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connection tool with no annotations and no output schema, the description covers purpose, usage, and a key limitation. However, it omits operational details like the behavior of inlet/outlet arguments, how errors are reported, and whether the connection replaces existing ones. It is adequate but not complete for an agent that must invoke it correctly.
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. It mentions 'stable ids,' which loosely maps to sourceId and targetId, but it does not explain the meaning of inlet and outlet parameters, their relationship to the objects, or how to choose valid values. This leaves significant param semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Connect two agent-created live objects by stable ids.' It clearly distinguishes this tool from siblings by naming pd_live_replace_graph as the preferred alternative for full patch updates, and by noting the restriction on direct signal-to-dac~ connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Use only for small follow-up edits') and provides an alternative ('prefer pd_live_replace_graph for full patch updates'). It also documents a meaningful constraint ('Direct signal-to-dac~ connections are blocked'), giving clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation via 'Return' and 'preview' in the title, but does not explicitly state that it has no side effects or what occurs if no patch has been generated. The mention of 'Vanilla .pd patch text' adds useful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only preview tool, the description tells the agent exactly what it returns and implies the context ('current generated'). Details about error states are unnecessary given the simplicity.
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?
The tool has zero parameters, so there is nothing for the description to explain beyond what the schema already conveys. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Return') and resource ('current generated Vanilla .pd patch text'). It distinguishes from siblings like pd_open_patch or pd_save_patch by emphasizing it returns the current generated text rather than loading or saving.
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?
The usage is implied (use to inspect the current generated patch text), but the description does not explicitly state when to use it over alternatives like pd_live_graph or pd_status. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a key side effect: rebuilding the visible MCP live canvas after removal. However, it does not mention irreversibility, what happens if the id does not exist, or whether there are any prerequisites, which leaves some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and the follow-up side effect. There is no redundant or vague wording, making it optimally concise.
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 one-parameter removal tool, the description is adequately complete. It identifies the target (agent-created connection by stable id) and the consequence (canvas rebuild). It does not detail error behavior, but this is not essential for a simple inverse of pd_live_connect, especially with no output schema.
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?
The schema describes the 'id' parameter with a pattern but no description. The tool description adds the semantic clue that this is a 'stable id' for an agent-created connection, which helps the agent infer that this is the id returned from a previous connect operation. This compensates well for the otherwise bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes an agent-created live connection using a stable id, and also notes that it rebuilds the visible canvas afterward. This specific verb+resource+method distinguishes it from sibling tools like pd_live_connect and pd_live_remove_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'agent-created live connection' provides clear context that this tool is intended for connections previously created by the agent, and 'stable id' indicates the id comes from a prior creation. It does not explicitly name alternatives or when-not-to-use scenarios, but the scope is clearly delimited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![PureData-MCP MCP server](https://glama.ai/mcp/servers/damagethundercat/PureData-MCP/badges/card.svg)](https://glama.ai/mcp/servers/damagethundercat/PureData-MCP)

Score Badge

Copy to your README.md:

[![PureData-MCP MCP server](https://glama.ai/mcp/servers/damagethundercat/PureData-MCP/badges/score.svg)](https://glama.ai/mcp/servers/damagethundercat/PureData-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/damagethundercat/PureData-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server