obj_run_process

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 discloses the return type but says nothing about the arbitrary, potentially destructive nature of running any Altium process, required preconditions, or side effects. For a generic escape-hatch tool with zero annotation coverage 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence followed by structured Args/Returns sections; no filler. The examples are directly useful, though the section headers take some space that could be trimmed.

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?

An output schema exists, so return values needn't be detailed, and parameter mechanics are well covered. However, for a generic command-execution tool with no annotations, the missing guidance on when to use it versus specific siblings and the lack of any safety/behavioral disclosure leave clear gaps.

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 coverage is 0%, so the description must compensate, and it does: it gives example process identifiers ('Sch:Compile', 'WorkspaceManager:OpenObject', 'PCB:Zoom') and explains the pipe-separated key=value format for parameters with a concrete example. This adds substantial meaning beyond the bare schema.

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?

States a specific verb+resource: 'Run an Altium process command via the generic primitive layer' and clarifies it wraps any RunProcess call. An agent can tell what it does, but the description does not explicitly distinguish it from the many specific sibling tools (e.g. app_run_ui_command, proj_run_output, pcb_* operations) that also execute actions.

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 never says when to use this generic primitive versus the dozens of specific sibling tools, nor when not to use it. The phrase 'generic primitive layer' hints at an escape hatch but leaves the agent to infer the selection rule.

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