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

With no annotations, the description carries the full burden, and it partially meets it by describing a composite return ('card + children + routing hints'), which signals a read-only traversal. It says nothing about invalid/missing refs, permissions, rate limits, or the cost of deep traversal, so an agent calling with an unknown ref gets no expectation-setting.

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 accepted-input list plus return shape are front-loaded before any elaboration. Every clause conveys information an agent can act on.

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 one-parameter tool with an output schema that already documents return values, the description covers both what to pass in and the shape of the payload. The remaining gap is routing relative to sibling discovery tools, which keeps it from being fully self-sufficient.

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% for the single 'ref' parameter, so the description must compensate, and it largely does by listing the five accepted identifier formats. It stops short of giving format examples, prefix syntax, or whether a slug vs an id resolves differently.

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 ('deep-dive') plus the resource ('any Lab entity') and enumerates the five accepted ref kinds (dataset slug, repo name, domain slug, source id, analysis slug), which is unusually concrete. It does not contrast itself with discovery siblings like find or lab_map, so an agent must still infer its place in the suite.

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 only implied: you call it when you already have a 'ref' to an entity. There is no explicit when-to-use or when-not-to-use, and no mention of the obvious alternatives in the sibling set (find, lab_map, workspace_triage) or how choosing explore over those changes the outcome.

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

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

With no annotations, the description carries the full burden and discloses meaningful behavior: all query tokens must match with cross-field AND, search spans slug/name/tags/description/source_id/column schema, and include_github=true requires GITHUB_TOKEN and adds open issues/PRs plus top org Discussions. It does not explicitly state that the operation is read-only or describe pagination/rate-limit behavior, which keeps it from 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?

The description is dense and front-loaded: search scope and matching behavior come first, then filters, return summary, the explore redirect, and the include_github extension. It is appropriately sized, though a short structured layout would improve scanability.

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 5-parameter search tool with no annotations and no schema descriptions, the description supplies enough context to invoke it correctly: matching rules, filter values, special flag behavior, auth requirement, and a brief return summary. Since an output schema exists, it need not explain return values in depth, but minor gaps around limit behavior and read-only status remain.

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%, so the description must compensate, and it does for the most important parameters: it explains query matching semantics and search fields, lists the allowed type values, and explains include_github's behavior and auth requirement. It says less about domain and limit beyond naming them, leaving default/max limit semantics implicit.

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 specific verb and resource set: 'Ranked search across datasets, repos, domains, sources, and analyses.' It also differentiates from the sibling tool explore by saying 'Use explore(ref) for details,' so an agent can tell when find is the entry point rather than the detail viewer.

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?

It gives clear usage context through the type filter values and the include_github flag, and explicitly routes detail retrieval to explore(ref). It does not give explicit when-not-to-use guidance against other search-adjacent siblings, but the intended role is clear.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation read-only, restricts to public buckets, requires a single statement referencing `_data`, allows CTEs, and caps output at 500 rows (default 100). What it omits is failure behavior for invalid SQL or query cost/time limits, which would complete the behavioral picture.

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?

Purpose is front-loaded and every sentence adds a real constraint (layer mapping, `_data` table, statement count, limit, discovery, exclusions). It is slightly dense in the slug/layer sentence and reads as one long block, but nothing is wasted.

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 4-parameter query tool with no annotations but an output schema, the description covers everything an agent needs to call it correctly: which datasets, the required table name, SQL restrictions, row limits, and how to discover valid slugs. Return-value explanation is correctly left to the output schema.

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 compensate, and it does for all four parameters: slug (clean dataset slug vs mart dataset__table form), layer (clean default / mart), limit (default 100, max 500), and sql (must reference `_data`, single statement, CTEs permitted). The layer values are conveyed even though the schema defines no enum.

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 scope: read-only SELECT over datasets published in the Lab's public clean/mart buckets. It immediately distinguishes the two layers and names the sibling tools (find/explore) and the MCP toolkit for everything outside published data, so an agent can tell it apart from general query/data tools without opening a schema.

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?

Explicit when-to-use (only for published clean/mart data) and when-not ("per raw/contratti/pipeline usa il MCP toolkit"), plus a concrete discovery path: use find()/explore() to obtain slugs, with explore also returning columns and gcs_path. Nothing about selecting this tool is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It reveals only that this is an additive write ('aggiunge'), with nothing about permissions, failure modes on locked/archived discussions, or whether retries duplicate the comment.

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 front-loaded sentence with no filler. It is efficient, but the brevity comes at the cost of the behavioral and parameter detail noted above.

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 mutation tool with no annotations and 0% schema description coverage, the description is too thin; only the output schema relieves it of explaining return values. An agent cannot determine required permissions, the repo default behavior, or expected failure modes from this text.

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% across three parameters, so the description must compensate and largely does not. It indirectly implies that 'body' is the comment text and 'number' identifies the target Discussion, but says nothing about the repo_full_name default ('dataciviclab/dataciviclab'), which is a significant silent behavior.

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: adding a top-level comment to a GitHub Discussion. The 'top-level' qualifier usefully distinguishes it from a reply mechanism, though no sibling (e.g. github_create_discussion, github_get_discussion) is named for contrast.

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 explicit when-to-use or when-not-to-use guidance, and no mention of prerequisites such as needing write permission or an unlocked discussion. The only implied guidance is the word 'top-level', which hints at a contrast with threaded replies but never explains it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses useful behavior for category_name resolution (case-insensitive, accepts name or slug) and the default repo/hub, but says nothing about authorization requirements, visibility/permissions of the created discussion, or failure behavior for an invalid category.

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, front-loaded with the action and default, followed by the parameter nuance. No filler; the mixed Italian/English phrasing is slightly awkward but does not impede comprehension.

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 values need not be explained, and the category-resolution rule is covered. However, for an unannotated write tool with 0% schema description coverage, the absence of any permission/auth or side-effect caveats leaves a real gap.

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%, so the description must compensate — and it does for the two non-obvious parameters: category_name (name or slug, case-insensitive, with a concrete example) and repo_full_name (explicit default). body and title are left implicit, which is acceptable given they are self-evident strings.

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 ('Crea una GitHub Discussion') along with the scoping constraint (a category in the repository), which distinguishes it from github_list_discussions and github_get_discussion. It does not explicitly contrast with github_add_discussion_comment, but the creation semantics are 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?

Points the agent to github_list_discussion_categories to discover valid category options, and states the default repo so the caller knows repo_full_name is optional. It stops short of saying when NOT to use it (e.g., commenting on an existing discussion), but the routing guidance for the key ambiguity is present.

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

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

No annotations exist, so the description carries the full burden and does substantial work: it discloses the default full-body behavior, backward compatibility, that summary truncates at excerpt_chars=500, and that include_comments pulls nested replies in the same round-trip (avoiding extra calls). It omits auth requirements, error behavior for a missing number, and any rate-limit or size caveats for full bodies.

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 dense paragraph with the resource statement front-loaded and each subsequent clause tied to a parameter or mode. No filler, though the packed parenthetical enumeration of comment parameters is harder to scan than a short bulleted form.

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 an 8-parameter read tool with an output schema (so return values need not be explained), the description covers mode selection, excerpt sizing, and nested-comment retrieval — everything needed to invoke it correctly. Only the unmentioned repo_full_name default is a residual gap.

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?

With 0% schema description coverage, the description compensates by documenting 6 of the 8 parameters, including the mode values (full|summary), their defaults, and the comment-related knobs (comments_mode, comments_limit, comments_excerpt_chars). The notable gap is repo_full_name, which is never mentioned even though it defaults to a hard-coded repo (dataciviclab/dataciviclab) — an agent could silently query the wrong repository.

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 specific verb+resource ('Restituisce una GitHub Discussion'), which is immediately distinguishable from the sibling list tool github_list_discussions. It does not explicitly name the list sibling as an alternative, but the singular-resource scope makes the distinction clear.

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 only implied: fetch one discussion, choose summary vs full and opt into comments. There is no explicit 'use this when... / do not use when...' guidance, and no mention of when to prefer github_list_discussions or how to route between summary and full modes (e.g. token budget).

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

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

With no annotations, the description carries the full burden; it implies a read-only enumeration of repository configuration but never states auth requirements, whether the call is rate-limited, or pagination behaviour. It does add the returned field names, which is mild value given an output schema exists.

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?

One sentence, front-loaded with the action and the return fields, ending with the practical rule. Nothing extraneous.

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 one-parameter list tool with an output schema, the description covers purpose, what it returns, and its role in the discussion-creation workflow. The remaining gap is the repo_full_name format/default, which is not addressed anywhere.

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% for the single parameter repo_full_name, and the description only implies repository scoping ('di un repository') without explaining the owner/repo format or warning that the default is a hard-coded repo. The schema alone leaves the agent guessing at the expected format.

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 (list valid discussion categories of a repository) and even enumerates the returned fields (name, slug, is_answerable). This clearly separates it from github_list_discussions, which lists discussions rather than their categories.

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?

Explicitly tells the agent to call it before github_create_discussion so the category_name is correct — a concrete when-to-use rule tied to a named sibling. It does not state any when-not condition, but the usage context is unambiguous.

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

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

With no annotations, the description carries the full burden and does disclose significant behavior: default repository, default ordering by UPDATED_AT descending, cursor pagination with 'after'/'before', switch to server-side full-text search when query/category_name are supplied, and that category_name is a GitHub qualifier rather than a client-side filter. It stops short of stating read-only safety, authentication needs, rate limits, or error behavior.

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 dense, front-loaded sentences with no filler: the default scope is stated first, then the no-query mode, then the query-mode behavior and its pagination caveat. Every clause carries operational 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?

An output schema exists, so return values need not be described, and the description covers the default repo, both modes, ordering, and pagination differences. The main remaining gap is the undocumented 'limit' parameter and missing read-only/auth context, but the definition is largely sufficient for correct invocation.

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%, so the description must compensate; it adds meaning for after/before (cursor pagination), query (triggers full-text search mode), category_name (GitHub qualifier semantics), and repo_full_name (default value). The 'limit' parameter is left entirely undocumented, which is a real gap given zero schema coverage.

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 states a specific verb and resource ('Elenca le GitHub Discussions di un repository') and names the default repository, so an agent knows exactly what it returns. It is distinguishable from siblings like github_get_discussion and github_list_discussion_categories, though it never explicitly contrasts itself with them.

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?

It explains the two invocation modes (no query/category vs query/category_name) and their differing sort and pagination behavior, which is useful context. But it gives no explicit when-to-use versus alternatives such as github_get_discussion or github_list_discussion_categories, leaving selection to inference.

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

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses that unknown domains return ok=false with valid domain slugs, but it does not state that the tool is read-only, whether it has side effects, or other operational behavior.

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 with the hierarchy description front-loaded and the parameter behavior immediately after. Every sentence adds information; there is no filler.

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?

The tool is simple, has an output schema, and the description covers the hierarchy and the key error case. It is nearly complete, though it lacks guidance on when to use this versus sibling exploration tools and does not state its read-only nature.

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 compensate for the single domain parameter. It explains that domain selects an editorial theme, implies omission returns the full map, and documents the failure mode for unknown values, adding meaningful semantics beyond the bare schema.

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 clearly identifies the tool as a lab navigation map showing the domains → repos → sources hierarchy. It does not distinguish this from siblings like explore, session_bootstrap, or workspace_triage, so it is clear but not sibling-differentiating.

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?

It gives concrete usage for the domain parameter: use domain= to focus on one editorial theme, and explains the error behavior for unknown domains. However, it never states when to choose lab_map over explore or other navigation/discovery siblings, leaving the relative usage implicit.

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

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

No annotations are provided, so the description carries the full disclosure burden. It hints that output is 'compact markdown' (useful for token-cost expectations) but never states that the call is read-only, has no side effects, requires no arguments, or is safe to call repeatedly — all things an agent needs to know before invoking an unannotated tool.

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 phrase with the intent ('quick orientation') front-loaded and no filler. It is efficient, though its brevity borders on under-specification rather than tightness.

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 values need not be described, and a zero-argument tool is trivially invocable. What remains missing is content scope — what sections 'Lab state' covers and why this is preferable to the overlapping siblings — leaving the agent to call it speculatively.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the schema is trivially complete. The baseline of 4 applies; the description neither adds nor omits parameter meaning.

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 says it returns a 'compact markdown overview of Lab state', which gives a resource and an output form, but 'Lab state' is never defined and the verb ('bootstrap'/'orient') is implied rather than stated. Siblings like lab_map, explore, and workspace_triage plausibly also give overviews, and the description does nothing to distinguish this from them.

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?

'Quick orientation' implies the tool is meant to be called at the start of a session, which is a usable implied usage cue. However, there is no explicit when/when-not guidance and no named alternative among lab_map, explore, or workspace_triage, so the agent must guess whether this or one of those is the right entry point.

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

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

With no annotations, the description carries the full burden. It does disclose the key behavioral trait, that the default call returns a compact summary and section narrows the payload, but it says nothing about read-only semantics, permissions, payload size, or what happens with an invalid section value.

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?

Three short sentences, front-loaded with the core identity, then the default behavior, then the parameter enumeration. No filler and nothing to trim.

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 shape need not be explained, and the single parameter is fully enumerated. The only remaining gap is the absence of a read-only/side-effect statement now that no annotations are supplied.

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 'section' is typed as a bare anyOf string with no enum, so the description is the only source of valid values; it supplies all seven (radar, prs, issues, discussions, registry, git, warnings). It stops short of saying whether invalid or multiple values are accepted, which keeps it from a 5.

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 identifies the resource clearly, a machine-readable snapshot of Lab state, and enumerates its constituent sections (radar, prs, issues, discussions, registry, git, warnings), which effectively defines scope. It does not name or distinguish itself from siblings such as lab_map or session_bootstrap, so it falls short of a 5.

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?

It gives useful guidance on calling conventions: omit section for a compact summary, pass section to target a part. However, it never states when to prefer this tool over lab_map, explore, or session_bootstrap, so usage relative to alternatives is only implied.

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