Read Pine-generated label text, prices and native coordinates.
Read Pine-generated label text, prices and native coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| entity_id | No | ||
| target_id | No | Exact Chrome tab target ID from browser_list_tabs. Required for changes. | |
| expected_layout_id | No | Expected saved-layout ID. A mismatch stops the operation before writing. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only 'Pine-generated' context and does not explain pagination behavior, default limits, whether an empty result means no labels vs no chart, or why idempotentHint is false for a read operation.
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?
A single short sentence with the resource front-loaded and no filler. It is efficient, though efficient at the cost of under-specifying the call contract.
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?
With no output schema, the description does at least enumerate the returned values (text, prices, native coordinates), which is the minimum an agent needs for a read tool. However, for a 5-parameter paginated read exposed alongside four sibling Pine readers, it omits filtering, paging, and scoping details that materially affect a correct call.
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 only 40%, and the description says nothing about limit/offset paging, the entity_id filter, or how target_id scopes the read to a Chrome tab. Those parameters are left to their bare types, so the description fails to compensate for the coverage 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?
States a specific verb (read) and resource (Pine-generated labels), and names the returned fields (label text, prices, native coordinates), which distinguishes it from data_get_ohlcv/study_values. It does not explicitly differentiate itself from the other Pine drawing readers (lines, tables, boxes), leaving that inference to the name.
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?
There is no when-to-use guidance, no mention of prerequisites (chart open, script running, target tab), and no routing to alternatives such as data_get_pine_lines for line objects. The agent must infer everything from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.