List all TI processes in the TM1 model, including control processes when needed. Use to identify available TurboIntegrator routines for execution or review.
List TI processes.
| Name | Required | Description | Default |
|---|---|---|---|
| includeControl | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. The verb 'list' reasonably implies a read-only operation, but the description does not explicitly state that there are no side effects, what the return payload contains, or whether control processes are included by default.
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 a single efficient sentence with no filler or redundancy. The verb and object are front-loaded, so an agent can immediately grasp the purpose.
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?
Given no output schema, no annotations, and an undocumented optional parameter, the description is too sparse for fully informed invocation. An agent can call the tool with no arguments, but it cannot reason about includeControl or the expected return format.
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?
The schema has no description for includeControl (0% coverage), and the tool description does not mention or explain it. The parameter name is somewhat self-explanatory, but the description adds no semantic value to compensate for the missing schema documentation.
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 names a specific action ('List') and resource ('TI processes'), making it immediately clear what the tool does. It also distinguishes this tool from sibling list tools for views, cubes, and dimensions.
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 no guidance on when to prefer this tool over alternatives, nor does it mention related tools like tm1_get_process_code. The agent is left to infer usage context solely from the tool name and the one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.