Read board_config.json settings—whole configuration or a single key like retrieval_mode or abstain_threshold—to inspect tuning values without editing the file.
Прочитать board_config.json (тюнинг без правки файла): весь конфиг или один ключ (retrieval_mode, abstain_threshold, hybrid_alpha…).
| Name | Required | Description | Default |
|---|---|---|---|
| key | No |
Changes observed during successful MCP inspections.
v0.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It usefully discloses the read-only, non-mutating nature ('без правки файла'), which is genuine behavioral context beyond the schema, but says nothing about permissions, response format, or failure modes.
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 compact sentence that front-loads the resource and its read-only constraint, then the scope. No filler; the ellipsis hints at additional keys without bloating the text.
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 low-complexity read tool with one optional param, no output schema, and no nested objects, the description covers resource, scope, and safety adequately. Only a note on the returned structure would add value.
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% and the single 'key' parameter is a bare string, so the description must compensate. It does by explaining that key selects one config entry and gives concrete examples (retrieval_mode, abstain_threshold, hybrid_alpha), clarifying intended values where the schema offers nothing.
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 (board_config.json), plus scope: the entire config or one key. The parenthetical 'тюнинг без правки файла' distinguishes it from the write-side sibling config_set, though it does not name that sibling explicitly.
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?
Implies read-only usage versus file modification, giving the agent context for when to pick this over config_set, but it never names the alternative or states conditions/exclusions explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.