Locate a specific variable in an IC-CAP object's child variable table using the object path and variable name. Specify the object type to disambiguate when multiple objects share a path.
Find a variable in the child variable table of an object.
| Name | Required | Description | Default |
|---|---|---|---|
| var_name | Yes | Variable name without a path | |
| object_path | Yes | ||
| object_type | No | Specify the exact IC-CAP type when a path can name more than one object. |
Changes observed during successful MCP inspections.
v0.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of explaining behavior. It does not disclose whether the search is recursive, what the return value looks like, how object_type affects results, or what happens when the variable is not found. 'Find a variable' implies a read operation but adds little beyond that.
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 sentence with no wasted words and states the core purpose upfront. It is concise and scannable, though it achieves this by being extremely thin on supporting detail.
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 tool with three parameters, an enum, no output schema, and no annotations, this one-sentence description leaves important gaps. An agent cannot infer return behavior, path syntax, or when to prefer this tool over object_find_var. The description is minimally adequate but not complete enough for confident invocation.
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 67%, with object_path left undocumented, and the description does not compensate for this gap. It does not clarify what 'child variable table' means in relation to object_path, nor does it explain how var_name and object_type interact. The description adds minimal meaning beyond the 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?
The description states a clear action ('Find') and a specific resource ('a variable in the child variable table of an object'), which is more specific than the tool name alone. However, it does not explicitly differentiate from the sibling object_find_var, leaving some ambiguity about the boundary between the two lookup tools.
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?
No guidance is provided about when to use this tool versus alternatives such as object_find_var or object_get_child. The description only says what it does, not when it should be selected or when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.