get_overview

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

With no annotations present, the description carries the full disclosure burden and does so thoroughly. It reveals compact-by-default output, the `more` field, char-limit behavior, `_meta` reduction reporting, and the "projections, not omissions" semantics for gated blocks. This gives an agent an accurate mental model of side effects, output shape, and cost implications beyond the raw schema.

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 front-loaded with its core value proposition and then organized into clear sections: returns, when-to-skip, default behavior, workspace modes, and args. It is long, but nearly every detail earns its place; minor redundancy exists between workspace mode bullets and the repo arg line, though this does not meaningfully hurt clarity.

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 an output schema exists and both parameters are thoroughly documented in prose, the description supplies all essentials: what the tool returns, how to request extras, how workspace scoping changes results, and how large payloads are managed. No critical operational information required to invoke or interpret the tool appears to be missing.

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%, but the description fully compensates with an Args section explaining repo as alias/path/ID and "all", and enumerating every include value with the exact block each one activates. The semantic meaning is far richer than the bare schema, which only says two nullable fields with defaults.

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 opens with a crisp job statement — "Architecture map for an unfamiliar repo" — and enumerates the concrete contents: overview summary, key modules, entry points, architecture layers, code health, and git health. It also distances itself from later-stage siblings by naming get_context / get_answer as follow-ups, so the tool's place in a workflow is unmistakable.

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?

Usage is explicit: this is the "first call when you don't know your way around," and it should be skipped once the map exists in favor of get_context / get_answer. Workspace-mode behavior is fully specified for omitted repo, repo="all", and repo="<alias>", leaving no ambiguity about when each call shape is appropriate.

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