Extracts a function map with line numbers plus only task-relevant excerpts from large files, avoiding full-file reads to reduce token use.
Lê um arquivo grande pela metade do custo: mapa das funções com linhas + só os trechos ligados à tarefa. Use no lugar de abrir o arquivo inteiro quando ele passar de ~150 linhas.
| Name | Required | Description | Default |
|---|---|---|---|
| tarefa | Yes | ||
| arquivo | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It does disclose the single most important trait — that the caller will NOT receive the whole file, but a function map and a task-filtered subset — plus a cost claim. It says nothing about failure modes (file not found, no matching excerpts), truncation limits, or file-type constraints.
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?
Two compact sentences, front-loaded with the value proposition and mechanism before the routing instruction. Nothing is filler, though 'pela metade do custo' is a loose quantitative claim that earns its place only as a heuristic.
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-value detail is not required, and with only two required params the description's coverage of mechanism and trigger threshold is close to sufficient. Remaining gaps are edge-case behavior and the fact that selection is heuristic, so the output may miss content the agent expects.
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 carry the semantics. It implies both roles well: 'arquivo grande' anchors the file parameter and 'trechos ligados à tarefa' anchors the task parameter as the relevance filter. It adds no guidance on path format (relative/absolute) or on how specifically the task string should be phrased to steer selection.
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 pairs a specific verb (lê/read) with a specific resource (arquivo) and explains the mechanism: a function map with line numbers plus only task-relevant excerpts. It is clearly distinguishable from summarize-style siblings, though it never names a concrete sibling tool for the 'read the whole file' alternative it positions itself against.
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?
Gives an explicit trigger condition ('when the file exceeds ~150 lines') and an explicit alternative behavior ('use instead of opening the whole file'). It stops short of stating exclusions, such as when a caller genuinely needs the complete file content or when the file is small enough that the overhead is not worth it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.