Retrieve parameter precision and working precision of an IC-CAP object by specifying its path and type, clarifying ambiguity with the object_type field.
Get parameter precision and working precision of an IC-CAP object.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 provided, the description carries the full behavioral burden. 'Get' implies a read-only operation and no side effects, which is useful, but the description does not disclose what the returned precision values look like, how errors are handled, or what 'working precision' means in practice.
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 that front-loads the core purpose without unnecessary words. It is appropriately concise, though it could afford a bit more detail without becoming bloated.
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 the lack of annotations and output schema, the description is incomplete for a reliable agent call. It does not explain the return format, path syntax, or when the optional object_type should be supplied. An agent understands the high-level intent but lacks enough detail to invoke the tool with confidence.
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 covers object_type with an enum and description, but object_path, the only required parameter, has no description. The tool description does not compensate by explaining path syntax or when object_type is necessary. With only 50% schema coverage and no additional parameter guidance, this is a meaningful gap.
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 a specific verb ('Get') and resource ('parameter precision and working precision of an IC-CAP object'). It is not a tautology and differentiates itself from generic getters like object_get_val or object_get_path, though it does not explicitly name any sibling alternatives.
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 sibling tools such as object_get_val or object_get_path. There are no usage conditions, exclusions, or alternative recommendations, so an agent must infer when this getter is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.