Load a .tox component into a designated parent COMP, ensuring the file path is within allowed project roots.
Load a .tox into a parent COMP. Path must be under the project folder or $TOUCHBRIDGE_TOX_ROOTS; .toe refused.
path (<class 'str'>): The .tox file.
parentPath (str | None): COMP to load into (default '/project1').
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| parentPath | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must carry the behavioral burden. It does disclose file-type restrictions and path constraints, but it does not describe side effects, success/error outcomes, or what happens if the parent COMP is invalid. Some transparency exists, but important behavioral details remain absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense. The primary action and constraints appear first, followed by clean parameter annotations. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small two-parameter mutation-like tool, the description covers the essential requirements and key edge cases. It lacks some outcome/error information, but it is adequately complete given the simplicity of the tool and the absence of nested objects or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the empty schema. It explains that path is the .tox file and parentPath is the COMP to load into, with an effective default of '/project1'. This adds meaningful semantics, though it could say more about how parentPath is resolved or validated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Load a .tox into a parent COMP.' It names the specific file type and target concept, and the file-type restrictions distinguish it from export/save siblings such as project_export_tox. An agent can understand what the tool does and what it applies to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage constraints: the path must be under the project folder or $TOUCHBRIDGE_TOX_ROOTS, and .toe files are refused. It does not explicitly name alternatives or say when not to use this tool, but it gives enough context to invoke it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.