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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds behavioral nuance by noting that dates come from 'the CPM engine next to the dates stored in the file,' indicating it presents both computed and stored values. This goes beyond the annotations to explain what data is included. However, it does not disclose potential edge cases like not-found behavior or performance implications, but the annotations cover the core safety profile.

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 a single sentence that front-loads the core purpose ('Everything about one activity') followed by a comma-separated list of attributes. It is efficient, with no wasted words, and the list is logically grouped (dates, floats, constraints, codes, assignments, relationships). It could be slightly more structured with line breaks, but it remains concise for the amount of information conveyed.

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 that there is no output schema, the description serves as the primary source for understanding the return value. It lists a comprehensive set of fields, which is helpful. However, it does not explain the meaning of specific terms like 'driving flag' or 'relationship float' beyond their names, and it omits any mention of error behavior or parameter prerequisites. Given the tool's complexity, this is a strong effort but still leaves some details to be inferred.

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 schema has 0% description coverage, so the description must compensate. It clarifies that the 'activity' parameter accepts an activity ID or an exact name, which is valuable. However, it provides no explanation for the 'path' or 'project' parameters. Since these are required (path) and optional (project) but not described anywhere, the description does not fully compensate for the schema gap. It leaves two of three parameters semantically undefined.

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 states the tool's purpose: it returns comprehensive details for a single activity, identified by ID or exact name. It lists the specific data fields (type, status, dates, floats, constraints, assignments, relationships), which distinguishes it from sibling tools like list_activities (which likely returns summaries of all activities) and schedule_summary. The verb is implied ('Get everything about one activity'), but the resource and scope are 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 implies that this tool is for retrieving detailed information about one activity, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. For example, it does not mention that list_activities is for browsing or that critical_path or driving_path focus on specific analyses. The usage context is clear from the description but not explicitly compared with siblings.

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=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the baseline source priority order, the labeling of P6 Planned Start/Finish as not a true baseline, and the positive/later-than-baseline sign convention. This goes beyond what annotations 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?

The description is a single dense paragraph that front-loads the core output (variance in working days, sort order) and then explains the baseline source priority. Every sentence earns its place, though the baseline source explanation is somewhat long and could be split for readability.

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 read-only analysis tool with no output schema, the description covers the key output (variance per activity, project finish variance), the unit, the sort order, and the baseline source resolution. It doesn't explain the limit or project parameters, but the tool is still callable with just path. The description is complete enough for an agent to select and invoke the tool 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 description coverage is 0%, so the description must compensate. It explains the meaning of baseline_path (a baseline schedule file matched on activity ID) and the fallback baseline sources, which helps with the baseline_path parameter. However, it doesn't explain path, limit, project, or baseline_project semantics beyond what the schema names provide. The description adds some meaning but not enough to fully compensate for 0% 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 ('variance of every activity against a baseline'), the resource (activities), the unit (working days), the sort order (worst finish variance first), and the additional project finish variance. It clearly distinguishes itself from siblings like schedule_summary or compare_schedules by focusing on baseline variance.

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 explains the baseline source priority order (baseline_path, MS Project Baseline 0, P6 Planned Start/Finish), which tells the agent when the tool will use which source. It doesn't explicitly name alternative tools to use instead, but the context is clear enough for an agent to know when to invoke this 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds diagnostic details (where Java and MPXJ jars were found) and clarifies that .xer/XML files don't require Java, which is useful behavioral context beyond the annotations.

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 with zero wasted words. The core output information is front-loaded, followed by a targeted usage hint and a clarifying note. It is both concise and well-structured.

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 parameterless diagnostic tool with no output schema, the description fully covers what it returns (version, config file, .mpp support details) and when to use it. It even mentions the .xer/XML exception, making it complete for the agent's decision-making.

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?

There are zero parameters, and schema coverage is trivially 100%. The description doesn't need to explain parameters since none exist. The baseline of 4 for 0 params is appropriate; the description adds no parameter-specific info but none is needed.

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 ('Show') and a clear resource: server version, config file, and .mpp support availability. It also provides a usage trigger ('Run this first if a .mpp file fails to open'), distinguishing it from sibling schedule-analysis tools by focusing on setup diagnostics.

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 explicitly instructs when to use the tool ('Run this first if a .mpp file fails to open') and provides a negative condition ('.xer and XML files never need Java'), effectively telling the agent when it may not be needed. This is clear, actionable guidance.

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=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: activities match on P6 Activity ID or MS Project Unique ID, the section parameter controls full-list output, and the report includes many specific comparison categories. It does not disclose edge-case behavior, but the annotations lower the burden.

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 the core purpose, which is good. However, the long enumeration of comparison sections is written as one dense run-on sentence and would be far more scannable as bullets or shorter sentences. The material is relevant but not optimally structured.

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 does a solid job of conveying both the tool's selection context and its output content: it lists all major comparison sections and the activity matching key. It omits the meaning of limit and the project parameters and does not describe the return format, but the core selection/invocation information is largely present.

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, but it only explains the section parameter ('Pass section=<name> for one section's full list') and the ID-matching rule. It does not clarify limit, previous_path, current_path, current_project, or previous_project semantics, leaving five of six parameters effectively undocumented.

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: 'Update-to-update comparison of two versions of a schedule (previous vs current update).' This clearly distinguishes it from sibling tools like baseline_variance, which would compare against a baseline rather than another update. The subsequent list of report sections reinforces what the tool produces.

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 gives clear context for when the tool is appropriate: comparing two schedule updates rather than, say, a baseline-to-current comparison. It does not explicitly name alternatives or state when not to use it, so it falls short of a full 5, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds substantive behavioral detail: traces driving relationships from latest finish, honors a threshold, and specifies row content (total float and driven indicator). This goes beyond the annotations and gives the agent a clear picture of the operation's semantics.

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 but efficient sentences carry a lot of information with zero fluff. The core purpose is front-loaded, followed by method variations and output row description. Every sentence earns its place.

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 description covers the output row contents and method behavior, which is helpful given no output schema. However, it leaves critical parameter semantics for 'path', 'limit', and 'project' unexplained, and doesn't clarify the meaning of the default 'limit' value (0). For a tool with 5 parameters and no output schema, this gap makes it less than complete.

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 define all parameters. It only explains 'method' and 'float_threshold_days'; the required 'path' and optional 'limit' and 'project' are left ambiguous. Out of 5 parameters, 2 are clarified, which is insufficient given the zero 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 clearly identifies the tool's purpose as retrieving the critical path in start order, with a specific verb implied ('get'/'list') and a specific resource. It distinguishes two methods, which helps distinguish it from siblings like driving_path, and the comparison to P6's Longest Path adds concrete domain grounding.

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 explains when to use each method ('longest_path' default vs 'total_float' with threshold), giving clear context for selecting the appropriate behavior. It does not explicitly name alternatives or exclusions, but the method-level guidance is strong enough for most agent decisions.

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=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: it reports per-check metric/threshold/pass-fail and example offenders, explains the baseline fallback chain (baseline_path -> stored baseline -> P6 planned dates labelled), and clarifies the float_source options (computed vs stored). This goes beyond the annotations and helps an agent predict 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?

The description is a single dense paragraph that packs a lot of information: purpose, check list, reporting format, baseline requirements, float_source options, and the special check parameter behavior. Each sentence contributes new value. It could be improved with bullet points for readability, but it is not overly verbose and front-loads the core purpose.

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 tool with 7 parameters and no output schema, the description covers the essential aspects: it lists all 14 checks, explains the reporting (metric, threshold, pass/fail, example offenders), details baseline and float_source options, and clarifies how to request a full offender list. It omits details on 'limit' and 'project', but these are likely auxiliary; overall the agent has enough to call the tool 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 description coverage is 0%, so the description must compensate. It explains 'check' (by name or number, e.g., '6_high_float' or '6'), 'float_source' (computed or stored), and 'baseline_path' (a baseline schedule file). It also mentions 'baseline_project' implicitly through the baseline context. However, it does not explain 'limit', 'project', or 'baseline_project' individually. Given the zero coverage, this partial compensation earns a 3.

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 states the tool's purpose: 'DCMA 14-point schedule assessment' with the specific checks enumerated. This distinguishes it from sibling tools like logic_check (which covers only one check) and compare_schedules (which compares schedules rather than assessing against DCMA thresholds). The verb and resource are 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?

It provides context on when to use the tool (for a comprehensive 14-point assessment) and notes prerequisites: 'Missed tasks / BEI / CPLI need a baseline' with fallback options. It also explains how to get full offender lists for a specific check (check='6_high_float' or '6'). However, it doesn't explicitly state when to use an alternative like logic_check for a single check, but the comprehensive nature is implied.

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?

The annotations already declare the operation as read-only and idempotent. The description adds behavioral depth by explaining the recursive expansion of driving predecessors and the stopping condition ('back to the activities driven only by the data date or a constraint'), which is not visible in the 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?

Two sentences, no fluff, with the core definition front-loaded and the practical use case immediately after. Every sentence contributes to understanding.

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 has four parameters, no output schema, and zero parameter-level documentation. The description gives a strong conceptual model but omits essential invocation details such as what 'path' means, how 'limit' affects the recursion, and how 'project' scopes the request.

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%, and the description does not compensate. It references 'activity' in the use-case sentence, but it does not explain 'path', 'limit', or 'project', leaving an agent without enough information to populate required parameters correctly.

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 defines the tool as a recursive trace of driving predecessors back to data-date/constraint drivers. It also gives a concrete user question it answers ('why is this activity forecast on that date?'), making its purpose distinct from sibling tools like 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 provides clear context by stating the tool is for explaining why an activity or milestone is forecast on a particular date. However, it does not explicitly mention alternatives or when not to use it, so it falls short of full routing guidance.

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 readOnlyHint=false and destructiveHint=false, the annotations alone would leave an agent guessing about side effects. The description resolves this with crucial safety disclosures: 'Never overwrites an existing file and never touches the schedule,' and explains the full dry_run contract ('returns the row count, columns and first rows without writing') plus the configuration gate for real writes (allow_writes=true in longpath.toml). This is exactly the behavioral context that matters for a file-writing 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?

Three sentences that are information-dense but earn their length. The purpose is front-loaded, the long tool enumeration is necessary because the schema provides no enums, and the dry_run/write mechanics are essential for a two-phase tool. It is on the verbose side, but no sentence 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 wrapper tool with no output schema, no enums, and 0% schema coverage, this description carries nearly the full burden and succeeds: it covers the source-tool contract, safety properties, dry_run return shape, and the prerequisite configuration for writing. The only real omission is the return value of a successful actual write (only dry_run's return is described).

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% and there are no enums, so the description must compensate entirely — and it does. It enumerates valid values for `tool`, explains that `arguments` are 'that tool's arguments (path, filters...)', and details `dry_run` behavior. The only slight gap: `csv_path` is implied by 'to a new .csv file' but never explicitly defined as the output file path.

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 pair: 'Write the FULL list behind one of the list tools to a new .csv file (Excel-friendly UTF-8).' This clearly distinguishes it from its siblings, which are all read/analysis tools that return data rather than write files. It also adds the scope qualifier 'FULL list' and 'never touches the schedule,' making its role 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 lists all 11 compatible source tools and flags the special argument requirements for some (check=..., section=...), giving practical guidance on when this tool applies. It also conveys the two-step usage pattern: default dry_run first, then dry_run=false with allow_writes=true for actual writing. It stops short of an explicit 'use X instead when...' statement, but since no sibling writes CSV files, the alternative-avoidance question is effectively answered.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds substantial behavior beyond that: it returns match count plus a computed total float in working days, explains that wbs includes everything below it, and defines critical_only as float <= project threshold.

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 but every sentence earns its place: the return shape is front-loaded, followed by a logically grouped filter list and the export alternative. No filler or redundant restatement of the schema exists.

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 14-parameter tool with no output schema, this description is unusually complete: it covers return fields, filter semantics, sort options, and the export path for unbounded results. The only gaps are the undefined `path`, `project`, and `limit` default semantics, which slightly reduce completeness.

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 carries the full burden, and it largely succeeds: wbs, code, status, activity_type, text, min/max_float_days, critical_only, longest_path_only, include_stored_float, and sort are all meaningfully explained. However, the required `path` parameter, `project`, and the exact behavior of `limit` (especially its default of 0) are not explicitly defined.

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: 'List activities with filters; returns the match count and the top limit rows...'. It enumerates the returned fields and distinguishes this from data-export siblings by explicitly pointing to export_csv for all rows.

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 explains when to use this tool versus export_csv: 'For all rows use export_csv(tool='list_activities', ...)'. It also makes the filtering use cases explicit by detailing each filter's purpose, which gives the agent clear selection criteria.

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 establish the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond those annotations by specifying the output contents, the optional calendar scoping, and the exception-count cap. It does not fully describe output shape or pagination, but the safety profile is already 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?

Two compact sentences with no filler. The primary behavior and return contents are front-loaded, and the optional usage guidance is delivered in a brief second sentence. Every phrase earns its place.

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 read-only listing tool with simple scalar parameters, the description is reasonably complete: it states what is listed, how to narrow to a single calendar, and the exception limit. The main missing piece is a direct explanation of the required `path` parameter, but the overall complexity is low and no output schema exists to contradict or supplement.

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 must compensate, and it partially does: it explains the `calendar` parameter (name or id) and `exceptions` (limit on exception dates). However, the required `path` parameter is only implied by 'in a schedule file' and is never explicitly tied to the path argument, leaving a meaningful 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 uses a specific verb ('List') with a clear resource ('work calendars in a schedule file') and enumerates the exact fields returned: work week, hours per day, exception counts, and activity usage. This level of specificity clearly separates it from sibling tools like list_activities or schedule_summary, even without naming 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?

The description provides clear context for when to use the tool: to get calendar definitions and usage counts. It also explains the optional narrowing behavior ('Pass calendar for one calendar with its exception dates'), though it does not explicitly contrast this with alternatives or state when not to use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context: results come from the CPM engine, lag is in working days of the predecessor, and relationship float is included. This goes beyond the annotations without contradicting them.

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 compact and front-loaded: first the core listing behavior and output fields, then the available filters. Every sentence contributes information, and there is no redundant restatement of the tool name or schema titles.

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 does explain the return values and the main filter options, which is helpful. But it omits the meaning of the required path parameter assured by the schema, the effect of limit, and any invocation context such as how path/project relate to the schedule file. An agent may still have to infer some call details.

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 carries the burden of explaining parameters. It does explain activity filtering (either end), rel_type values (FS/SS/FF/SF), lag range, and driving_only. However, it leaves the required path parameter and the limit/project parameters undocumented, so compensation is only partial.

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 clear verb and resource ('List relationships') and enumerates the returned fields: predecessor -> successor, type, lag in working days, driving flag, and relationship float from the CPM engine. This makes the tool's purpose unambiguous and distinguishes it from sibling tools that focus on activities, resources, or paths.

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 gives useful filtering context (activity, rel_type, lag range, driving_only), so the tool's main behavior is clear. However, it does not explicitly explain when to choose this tool over siblings like list_activities, critical_path, or driving_path, nor does it state any when-not-to-use conditions.

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=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details beyond that: it states totals are computed, expenses and fixed costs are summed on their own line, and results are sorted by largest budget cost first. These are meaningful behavioral traits not present in annotations, though it does not mention pagination or parameter effects on output.

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 a single sentence that front-loads the core purpose (resources with totals) and adds key output characteristics (sorting, grouping). It is concise and free of fluff, though it could be slightly more structured by separating the parameter semantics, but overall it is efficient.

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 has three parameters (one required) with zero schema descriptions, and the description does not explain what path, limit, or project refer to. There is also no usage guidance or mention of return format beyond textual description. An agent would struggle to correctly invoke this tool without additional context, making the description incomplete for the tool's complexity.

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 carries the full burden of explaining path, limit, and project. However, the description does not mention any of these parameters or their meaning, making it impossible for an agent to know what values to provide. The description only describes output, not inputs, so it fails to compensate for the missing schema descriptions.

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 states the tool lists resources assigned in the project with totals, including budget/actual/remaining units and cost, resource type, and how expenses are summed. It is specific about the resource focus and distinguishes it from sibling tools like list_activities or activity_detail, though it does not explicitly name an alternative. The verb 'list' is implied by the tool name and the description's phrasing, so it is clear but not maximally explicit.

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 guidance on when to use this tool versus alternatives such as list_activities or schedule_summary. The description only describes what the tool returns, not the context in which it should be selected. No exclusions or comparisons are provided, leaving the agent to infer usage from the tool name and sibling list.

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 mark the tool read-only/idempotent. The description adds real behavioral context: it returns counts plus a few examples for every check, and passing check=<name> returns that check's full list. This goes beyond the annotations and tells the agent what to expect from the 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?

The description front-loads the purpose, packs all check types into a concise list, and then adds one sentence on output selection. It is long but dense; each listed check contributes to the agent's understanding of scope.

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 output shape is described (counts with examples, full list on request) and annotations cover safety, so the agent can predict the general result. But with no output schema and key parameters like path and limit unexplained, the description is not fully complete for a tool with six parameters and one required input.

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 coverage, the description must carry parameter meaning. It explains check (check=<name> selects a full list) and max_lag_days (excessive lags threshold), and 'long durations' loosely maps to long_duration_days. However, the required path parameter is completely unexplained, and project and limit also lack meaningful semantics.

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 logic-quality sweep and enumerates specific checks (loops, leads, dangling starts/finishes, excessive lags, etc.), so an agent knows exactly what it audits. It doesn't use an explicit 'checks for' verb or name a sibling, but the checklist distinguishes it from computation tools like run_cpm or 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?

No guidance is given about when to choose logic_check over adjacent tools such as schedule_summary, driving_path, or compare_schedules. The checklist implies an audit use case, but there are no explicit conditions, exclusions, or 'use instead' signals.

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 convey read-only, idempotent, and non-destructive behavior. The description adds meaningful transparency about the algorithm's scope, including forward/backward passes, lag types, calendars, constraints, data date, retained logic, and progress overrides. It also explains what result is produced and how to interpret differences.

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 a single long sentence but front-loads the core action and packs useful detail without obvious filler. It could be split into more digestible sentences, but every clause contributes meaningful information about behavior, output, or interpretation.

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 description thoroughly explains the tool's purpose and output categories, but it omits any guidance on the required path parameter or the optional limit/project parameters. Since there is no output schema, the agent is also left without a precise return format, making the definition incomplete for fully 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%, and the description provides no explanation for any of the three parameters: path, limit, or project. An agent cannot infer what 'limit' or 'project' mean or how they affect execution. The description entirely fails to compensate for the missing schema-level parameter documentation.

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 action ('Run the server's own CPM engine') and a concrete resource, then details what the pass includes and what outputs are reported. It also distinguishes itself from sibling tools like critical_path by emphasizing a full engine run plus a comparison against saved float/early dates.

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 gives clear context: the tool is for validating or investigating discrepancies between a recomputed CPM result and the scheduling tool's saved values. It explains that differences may indicate settings, calendars, or stale files, but it does not explicitly name alternatives or state when not to use this 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it reads and parses a file, computes CPM-derived values (planned finish as computed by the CPM engine), and can emit errors listing projects when `project` is omitted. This goes beyond the annotations without contradicting them.

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 but well-organized: the main summary content is front-loaded, followed by the usage directive and parameter clarification. It is longer than the typical one-liner, but every clause adds information about what the tool returns or how to invoke it correctly. Slight redundancy in listing file formats twice could be trimmed, but it remains efficient.

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 read-only summary tool with no output schema, the description covers the input formats, the scope of the summary, the optional parameter, and the error behavior. It doesn't specify the exact output structure, but given the tool's purpose as a high-level overview and the absence of an output schema, the description is sufficiently complete for an agent 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 description coverage is 0%, so the description must carry the parameter meaning. It does: `path` is implied as the schedule file to open, and `project` is explicitly defined as 'short name or id, needed only when the file holds several projects.' This fully compensates for the schema's lack of descriptions.

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 ('Open... and summarize it') and a precise resource (schedule files with enumerated formats), then enumerates the exact summary contents. It clearly distinguishes itself from siblings like list_activities or run_cpm by being the first-stop overview 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?

Explicitly instructs 'Use this first on any new file,' which is a clear when-to-use directive. It also explains the `project` parameter's conditional necessity and what happens when it's missing (the error lists projects), effectively guiding the agent on when to supply 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?

Annotations already mark readOnly/idempotent/non-destructive, and the description adds beyond them: the source precedence for planned values (baseline_path, stored baseline, or P6 planned dates) and the linear spreading over working time. It also states the data-date comparison behavior. No contradiction with annotations.

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 compact and front-loaded with the core output, then expands into measure, period, resource, and baseline sources. It earns its place, though one dense sentence mixes several distinct facts and could be better structured.

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 tool with 8 parameters, no output schema, and no per-parameter schema descriptions, the description covers the main concepts but omits the semantics of several input fields (limit, project, baseline_project) and gives only a partial return-value picture. This is adequate with clear gaps.

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 does explain period, measure, resource, and baseline_path, but leaves limit, project, and baseline_project unexplained. This is a meaningful gap given 8 parameters.

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 producing S-curve/loading data by period with planned vs actual vs forecast and cumulative values, and it names supported measures and periods. It does not explicitly contrast itself with siblings like baseline_variance or schedule_summary, so not a full 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?

The description gives clear context for when the tool is appropriate: period-level loading/curves, cost/units/activities, resource histograms, and baseline vs actual comparison up to the data date. It does not explicitly state when-not-to-use or name an alternative, but the context is sufficient for choosing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns aggregated/rolled-up values (activity count including everything below, earliest start, latest finish, lowest total float), which tells the agent what kind of computation to expect. It doesn't disclose pagination or performance implications of deep max_depth, but the annotations carry the main safety burden.

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 a single sentence that front-loads the core purpose (WBS hierarchy) and then lists the computed fields. It is compact and every phrase adds information. It could be slightly more structured, but it is efficient and readable.

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 read-only tree tool with four parameters and no output schema, the description covers the main output shape and the key parameter (max_depth). However, it doesn't explain what path refers to (a WBS path? a project path?), what limit does, or how project interacts with path. Given the tool's moderate complexity, this is adequate but has clear gaps.

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 explains the meaning of max_depth ('down to max_depth levels') and implies the output structure, but it doesn't clarify the semantics of path, limit, or project. The description adds some meaning for max_depth but leaves the other three parameters to be inferred from their names and 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 clearly states the tool returns a WBS hierarchy down to a specified depth, with specific computed fields per node (activity count, incomplete count, earliest start, latest finish, lowest total float). This is a specific verb+resource combination that distinguishes it from siblings like list_activities or critical_path, though it doesn't explicitly name a sibling alternative.

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 implies this is for exploring WBS hierarchy with schedule metrics, and the max_depth parameter signals a drill-down use case. However, it doesn't explicitly state when to choose this over list_activities, schedule_summary, or driving_path, nor does it mention any exclusions or alternatives.

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