Import a Search Console CSV locally

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and closed-world safety; the description earns credit by adding what annotations cannot: processing happens in memory, files are neither uploaded nor persisted, and headers are auto-recognized in English and Indonesian. It does not cover behavior on unrecognized headers or size limits (only in schema), so not a 5.

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 sentences, no filler, and the core action is front-loaded ahead of the privacy caveat. Every clause contributes information.

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 should at least characterize the returned 'transparent summary' — it does not say what fields or counts come back. Combined with the undocumented columnMap and delimiter parameters, an agent has enough to call the tool but not to anticipate results or override parsing.

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 0% across three parameters, including a nested columnMap object with nine keys, so the description must carry the load. It hints that headers are auto-detected (implying columnMap is an override) but never mentions columnMap or the delimiter enum, leaving the two optional parameters unexplained.

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 and resource: parse a user-provided CSV/TSV Search Console export and return a summary. The 'user-provided ... in memory' framing implicitly separates it from API-backed siblings like edgeo_search_console_sites and edgeo_summarize_search_console, though it never names an alternative outright.

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?

The phrase 'user-provided CSV or TSV export' implies the case where the agent already has a local file rather than live API access, which is useful routing signal. But there is no explicit when-to-use/when-not or named alternative, so an agent must infer the boundary with the other Search Console tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.