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

Goes well beyond the annotations: it discloses that LOE and WBS summary activities are excluded even when P6 flags them, that completed activities are dropped unless include_completed=True, the exact ordering (total float then start, or float path order), and the precise semantics of each counts bucket including excluded_summary. That is exactly the kind of behavior an agent cannot infer from readOnlyHint/idempotentHint.

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?

Dense but nearly every clause carries operational meaning, and the purpose is front-loaded before the mode rules. The mode paragraph is a long run-on of semicolons and parentheticals that costs some readability, but trimming it would lose real constraints.

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, no-output-schema tool it documents the return envelope, paging, ordering, exclusions and counts semantics, which is most of what an agent needs to call it correctly. Remaining gaps are the unexplained envelope keys (schedule_state, note, definition) and no mention of failure behavior for an unknown project.

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 only 38% schema coverage, the description carries the load and mostly does: mode, float_threshold_days, min_float_days, include_completed and fields (deferred to p6_query_activities) all get meaning, while limit/offset/project are already described in the schema. A few envelope keys (definition, note, schedule_state) are named but never explained, so it falls just short of fully compensating.

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 resource and scope: critical activities of the last P6 schedule run, paged, with a named mode axis. An agent can tell it apart from p6_query_activities and p6_float_analysis by the critical-path framing, though the boundary with p6_float_analysis is only implied rather than stated.

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 clear guidance on the main variation axis: what 'project' (default), 'total_float' and 'longest_path' each mean, that the day-based thresholds cannot be combined with longest_path, and a worked example (min_float_days=0 with float_threshold_days=10 for near-critical). It does not, however, say when to prefer this tool over p6_float_analysis or p6_query_activities.

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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely new behavioral context: it operates without a database connection and enumerates the specific diagnostic fields it inspects, which tells the agent what evidence the call produces.

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 trigger condition before the enumeration of returned fields. The parenthetical list is dense but every item is informative rather than 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?

There is no output schema, but the description compensates by listing the contents of the diagnostic report, and annotations cover the safety profile. Nothing an agent needs in order to decide to call this and interpret the result is 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?

Zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. No parameter-level confusion is possible for this tool.

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?

Specific verb+resource (diagnose the P6 server configuration) with an explicit enumeration of what it reports: server settings in force, P6 schema/version, running state, backup and edit-log folders. This is clearly distinct from the data-retrieval siblings (p6_list_projects, p6_query_activities, etc.), so an agent can separate it 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?

"Start here when a tool reports a configuration problem" gives a concrete triggering condition, and "Works without a database" adds a precondition-free usage context. It does not, however, address the nearest sibling p6_health_check, so the boundary between diagnostics and health checking 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description nonetheless adds substantive behavior: exclusions (completed, LOE, WBS summary), bucket semantics including the guarantee that every value lands in exactly one bucket, the wrinkle that comparison happens in hours and is never rounded, and the internal consistency checks (no_value, all_ranges_covered).

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 purpose is front-loaded and nearly every clause carries functional information about bucket boundaries, output fields, or filters. It is a dense single paragraph with no visual structure, which hurts scanability for a long definition, but there is little filler to cut.

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 complex analytical tool with no output schema and low schema description coverage, the description is thorough: it defines the output shape (per-bucket total_float/free_float counts, percentages, samples), the stats block, and the integrity fields. An agent can interpret the result and call the tool correctly without further documentation.

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 only 25%, so the description must compensate. It explains edges_days bucketing in detail, restates sample_size's effect ('the sample_size lowest floats'), clarifies include_milestones, and covers wbs_name_contains / code_type / code_value / include_child_codes by delegating to p6_query_activities. The delegation rather than inline explanation keeps it short of a 5, since the agent must open another tool to fully understand the code filters.

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?

Names a specific computation (total and free float distribution) on a precisely scoped resource (open activities of the last F9), and explicitly excludes completed, LOE and WBS-summary activities. It also names the sibling whose filter semantics it mirrors (p6_query_activities), giving the agent a concrete anchor, though it never contrasts with p6_critical_path, the most adjacent tool.

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 implied (analyze float distribution of an activity set) and the filter parameters are explicitly delegated to p6_query_activities, which is useful routing. However, there is no explicit statement of when this tool is preferable to p6_query_activities or p6_critical_path, nor any stated prerequisites.

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?

Goes well beyond the safety annotations by disclosing result-shaping behavior: predecessors/successors and UDFs/notebooks are truncated to the first 50 with count fields, pagination is available via p6_get_relationships, and hours_per_day converts hours to days. This is exactly the kind of context annotations cannot provide.

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?

Front-loads the core purpose then lists field groups in one dense sentence; every clause maps to a returned element, so little is wasted, though the run-on list is heavy for a single sentence.

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 carries the burden of explaining returns and does so thoroughly, covering list fields, dates, calendar, WBS, relationships, assignments, codes and UDFs, plus truncation limits. An agent knows what to expect before calling.

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?

Both parameters are fully documented in the schema (100% coverage) with enough detail (Project ID per p6_list_projects, Activity ID task_code). The description adds no parameter-level syntax or format detail, so the baseline 3 applies.

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 ('Full detail of one activity') and enumerates the exact field groups returned. It is clearly distinguishable from p6_query_activities (list fields it references) and p6_get_relationships (paging path it references).

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?

Implied usage is clear ('full detail of one activity', with list fields delegated to p6_query_activities), and it explicitly routes the agent to p6_get_relationships when the capped predecessor/successor lists need more. No explicit 'do not use when' or prerequisites, so it falls short of a 5.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description rightly focuses elsewhere: it discloses the pagination contract (page shape with total/offset/returned/next_offset) and the non-obvious lag_rule calendar-conversion behavior. That is real behavioral context beyond structured fields, though it does not cover errors or empty-result 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?

Dense and front-loaded: the resource and page shape come first, then parameter semantics. Every clause carries information, though the return-field list and the lag sentences could be labeled more clearly (they read like fragments rather than an organized parameter/return block).

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 usefully enumerates the page fields and explains lag_rule, and annotations carry the safety profile. However, it never says what each row contains (relationship type, successor ID), whether direction=both duplicates rows, or that task_code alone may be ambiguous across projects.

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 80%, so limit/offset/project/task_code are already documented and the baseline is 3. The description adds meaning only for direction (pred/succ/both), and even there it restates the enum literals without expanding the pred/succ abbreviations, so it barely exceeds the 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?

States the resource precisely ("Relationships of an activity") and scopes it ("one page"), which clearly separates it from siblings like p6_get_activity or p6_query_activities. It never explicitly contrasts itself with those siblings, but the resource is unambiguous.

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 description never says when to call this tool versus p6_get_activity, p6_critical_path, or p6_float_analysis, nor does it state prerequisites (e.g., that an activity's task_code is needed). The only guidance is indirect, via the direction parameter values.

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?

Adds substantial behavior beyond the annotations: threshold resolution order (stored PROJPROP settings -> DCMA defaults -> thresholds= override), the pass/warn/fail banding rules, weighted_score arithmetic and grading, and the 'pass is None when not evaluated' convention. It also discloses the side effect that a full run saves a snapshot and how to skip it (save_snapshot=False) — something no annotation conveys. Minor gap: nothing says what happens when the project has no schedule run or the check name is invalid.

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?

Front-loaded with the purpose, but the body is a single semicolon-chained block of several hundred words with no headings, lists or paragraph breaks, mixing output structure, scoring rules and parameter semantics. Very little could be cut without losing information, but the chosen format makes the information expensive to parse — the opposite of what good structure should do.

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 10-parameter, no-output-schema, high-complexity tool, the description covers the returned keys (checks, key_dates, weighted_score, engine_version, legacy top keys) and the paging contract, so an agent knows what comes back. What is missing is edge-case behavior (no baseline present, empty schedule, invalid check name) and error signaling.

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 only 30% schema coverage, the description carries the burden and does so thoroughly: it defines baseline (Project ID, else project baseline), baseline_dates 'current' vs 'planned', duration_basis remaining vs original, thresholds= override semantics (by check name, not critical_path_test), high_float_days, and check= returning a paged list with result. Essentially every one of the 10 parameters gains meaning absent from the 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?

Opens with a specific verb+resource+scope: 'DCMA 14 point assessment of the last P6 schedule run (F9)', then enumerates every check performed. It distinguishes itself from siblings by naming p6_cpm_validate, p6_dangling and p6_health_check_compare in context. The density of the enumeration makes the core purpose harder to extract than it should be, keeping it below 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?

Usage is implied rather than stated: the critical_path_test is 'not run when the engine does not match the F9, see p6_cpm_validate', and snapshot saving points to p6_health_check_compare. However there is no explicit statement of when to pick this tool over p6_critical_path, p6_diagnose or p6_float_analysis, which is the primary selection decision an agent faces.

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?

Annotations already cover read-only/idempotent safety, and the description adds substantial behavior the annotations cannot convey: the pagination contract with next_offset, the exact template-project definition (status WS_Template or no EPS node), and the null-handling rule for projects outside every EPS node. These are the details that prevent wrong calls and misinterpreted results.

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?

It is front-loaded with the response envelope before the field list and parameters, and nearly every clause adds information. It is a dense, run-on block with heavy parenthetical nesting that would scan better as short bullets, but there is little wasted 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?

With no output schema, the description takes on the return-shape burden and does so explicitly, down to the page envelope and every row field including the three EPS columns. All six parameters are accounted for, so an agent has everything needed to call it and interpret the result.

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 only 33% (limit and offset only), so the description must carry eps, order, exclude_templates and include_baselines — and it does, including what 'eps' recurses into and what 'order=eps' means (EPS tree order as p6_list_eps order='tree', then Project ID, projects outside EPS last). This fully compensates for the schema gap.

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 by naming the resource and the exact return envelope ('Projects, one page: {total, offset, returned, next_offset, rows}') and enumerates the row fields, so an agent knows precisely what it gets. It also differentiates itself from p6_list_eps by stating 'EPS nodes are never listed'. The verb is only implied by the tool name rather than stated, which keeps it just 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 concrete conditions for each optional filter: 'eps= an EPS ID: the projects of that EPS node and of every EPS below it', 'baselines only with include_baselines=True', 'exclude_templates=True leaves out the P6 template projects'. It does not state when to reach for this tool over p6_project_summary or p6_query_activities, so alternative-selection guidance is incomplete.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context on top: pagination via next_offset, rollups=True expands each row to subtree totals, and explicit null conditions ('None without a baseline, a data date or baseline units') plus fallbacks ('actual, else early', 'open = not completed, LOE and WBS summary left out'). This is above what the annotations convey.

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 summary sentence is correctly front-loaded, but the rest collapses row-field definitions, parameter semantics and edge cases into one dense run-on block with inconsistent labeling. Nearly all the content is relevant, yet the wall-of-text form makes it hard to scan for the one detail an agent needs.

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 carries the full return contract (envelope keys total/offset/returned/next_offset/rows/root, per-row fields, rollup fields) and covers the tricky cases such as unplaced activities and bl_planned_pct nullability. It is thorough for a 7-parameter tool, though a short note on which sibling to prefer for flat activity queries would close the remaining 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 coverage is only 43%, so the description must compensate, and it largely does: baseline is described as a Project ID defaulting to the project baseline with the chosen one echoed in the result, parent accepts a full or relative WBS code like '5.1', max_depth counts levels below the start node, and rollups is defined by its effect. limit/offset are left to the schema, which documents them adequately.

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 first clause states a specific verb and resource: 'WBS tree in P6 order (each node before its children), one page'. That is unmistakably a WBS-hierarchy listing rather than an activity/project tool. It never explicitly contrasts itself with siblings like p6_project_summary or p6_query_activities, so it falls short of full sibling differentiation.

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. The description explains what parent and max_depth do ('starts at that WBS code', 'counts levels below the start node'), which hints at when to narrow the walk, but there is no explicit 'use this when you need X, use Y for Z' guidance and no mention of any sibling tool.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds substantial behavior: LOE and WBS summary activities are omitted, open activities use remaining dates with early-date fallback from the last F9, counts are computed over all pages while rows are paged, and results are ordered by start, finish, Activity ID. Missing only edge behavior such as what happens with an empty window or invalid dates.

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 lead sentence front-loads the return keys and the rest of the paragraph is dense but every clause carries behavior an agent would otherwise have to guess. Minor waste in listing the return keys twice (once as a brace list, then again in prose).

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 must carry the return shape and it does: it names every top-level key (total, offset, returned, next_offset, rows, window, weeks, data_date, counts, critical_definition, schedule_state, note) and explains per-row fields like fcst_start/fcst_finish and start_week/finish_week. For a 14-parameter, paginated, read-only tool this is sufficient to call it correctly.

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 only 21% across 14 parameters, so the description must compensate and largely does: from_date time defaults to 00:00, days/weeks are mutually exclusive window lengths, critical_only and include_completed/include_in_progress filter categories, and code_type/code_value/include_child_codes/fields/wbs_name_contains are explicitly delegated to p6_query_activities. limit and offset semantics are left to the schema, which covers them adequately.

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 ('Look-ahead of a project') and immediately enumerates the returned payload, so an agent knows exactly what this tool produces. It is clearly distinct from p6_query_activities and p6_critical_path, which it references only for parameter and definition conventions.

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 defines the selection window precisely (starts at data date or from_date, days= or weeks=, half-open interval) and spells out exactly which activity categories are listed or excluded. What it does not do is state explicitly when to choose this over p6_query_activities or p6_float_analysis; the routing is implied by the 'look-ahead' framing rather than stated.

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?

Annotations already cover read-only, idempotent and non-destructive, so the safety profile is free. The description earns credit beyond that by disclosing null/edge behavior with no output schema present: dates "None when it is unreadable", baseline keys "every key present, null without a baseline", and the explicit 0.01-point threshold for units_vs_physical_mismatch. It does not cover performance characteristics or pagination/size limits for what is clearly a heavy aggregate call.

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 run-on block of deeply nested parentheses enumerating every returned key. Key operational facts (what it does, what the baseline argument does) are not front-loaded and are hard to extract; a reader must parse the whole wall to find the parameter behavior. Not under-specified, but structurally poor and far longer than needed.

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, describing return contents is necessary and the description does that thoroughly, including derived-metric definitions (physical vs units %, SPI units, finish variance). However, it omits what an agent most needs for a heavy aggregate on a complex schema: prerequisites (project ID from p6_list_projects), expected size/latency, and clear selection guidance versus the narrower sibling tools.

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 50%: `project` is documented in the schema, but `baseline` (anyOf string/null) has no schema description. The text does convey the override logic – "the one used: baseline= else the project baseline" – which partially compensates, but the phrasing is ambiguous and buried inside a parenthetical about return fields rather than clearly stating that the `baseline` argument selects the comparison baseline. Partial compensation, not full.

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?

"One-call overview of a project" gives a specific verb+resource and scope. It also implicitly distinguishes itself from siblings by naming the equivalents it mirrors (p6_critical_path, p6_list_wbs, p6_progress_curve), so an agent can see this is the umbrella tool versus the single-concern ones. The remainder of the description is a field inventory rather than purpose statement, which dilutes but does not obscure the intent.

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 by "one-call overview" – i.e. reach for this when you want everything at once. There is no explicit when-to-use/when-not, no statement of cost or latency (which matters for a tool returning this many structures), and no routing advice such as "use p6_list_projects first to obtain the project ID". The sibling references describe semantic equivalence of returned values, not tool selection.

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?

Beyond the read-only and idempotent annotations, the description discloses the pagination envelope ({total, offset, returned, next_offset, rows}), row ordering, date-bound inclusivity, UDF filter conjunction behavior, and what code_filter/udf_filter report back. That is substantial behavioral context for an agent invoking a complex query 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?

The definition is dense but front-loads the core action, result shape and ordering before moving into filters. For a 16-parameter tool with low schema coverage, most clauses earn their place, though the single-block parenthetical style makes it harder to scan.

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?

It explains the return envelope, paging, ordering, common filters, WBS caveat, code matching and UDF behavior, which is appropriate given no output schema and sparse schema descriptions. Completeness is reduced because a few schema parameters, notably name_contains, code_prefix and max_total_float_days, are not described 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 description coverage is only 19%, so the description must carry parameter meaning, and it does for many important filters: status values, date format/inclusivity, wbs_name_contains scope, code_type/code_value matching, include_child_codes, fields projection, and UDF ops/output. It still leaves code_prefix, name_contains, and max_total_float_days unexplained, so it is strong but not complete.

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: 'Search activities, one page', and it defines the result envelope and ordering. It differentiates one sibling path by saying WBS-branch searches should use p6_list_wbs, but it does not explicitly contrast against other siblings such as p6_get_activity or p6_critical_path.

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 for paging, status filtering, date filters, code filters and UDF filters. It also names an explicit alternative for whole-WBS-branch queries ('use p6_list_wbs'), but it does not comprehensively explain when to choose this tool over the broader sibling set.

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