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

With no annotations, the description carries the full burden and does disclose two behavior-affecting traits: the specific safe defaults silently injected (MUMPS, direct solve for eigen/small driven, cheap estimator, Excitation = Index) and the conditional write triggered by 'out'. It omits overwrite semantics and error behavior on an invalid spec, which keeps it out of the top band.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense sentence with no filler; the purpose is front-loaded and the defaults, write condition, and return values follow in priority order. Slightly overloaded by the parenthetical default list, but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter generator with no output schema and no annotations, the description covers the essential decision inputs: what it produces, the defaults it silently applies, when it writes to disk, and that it returns lint plus schema results. Gaps on ram_gb/palace_version semantics and overwrite behavior are the main omissions.

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%: out and spec are documented, while ram_gb and palace_version are undocumented in both schema and description. The description compensates partially by enumerating what the spec contains (physical-group names, units, ports, sweep), which adds meaning over the schema's generic 'spec dict or path to a JSON file'.

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+resource: 'Build a Palace JSON config from a compact spec', with the input form (physical-group names, units, ports, sweep) made concrete. It is clearly a generation tool distinct from lint/run siblings, but it never names or explicitly contrasts an alternative, so it stops 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?

The conditional 'Writes it if "out" is given' gives real usage signal about when the tool persists output versus only validates. However, there is no explicit when-to-use guidance relative to siblings like palace_lint_config or palace_run; the workflow context (build before run) must be inferred.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether this reads files or executes a solver, whether it mutates anything, what permissions or a completed run it requires, or what happens on failure. Listing check names is not the same as disclosing 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?

A single front-loaded sentence with no filler, but it is an undifferentiated comma list of jargon that would benefit from grouping or structure. It is compact without being genuinely well organized.

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 (including nested objects), no annotations, and no output schema, the description is far too thin. It neither documents inputs nor clarifies what a check result looks like, leaving the agent unable to invoke it confidently.

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?

Seven parameters with 0% schema description coverage and no descriptions, and the description names none of them explicitly. There is only a loose implicit mapping (e.g. 'eigenmode at the expected frequency' ↔ expect.eigen_ghz, 'convergence' ↔ convergence, 'port symmetry' ↔ symmetric_pairs), leaving config, case_dir, output_dir, and reference_touchstone entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It gives a specific verb ('Sanity checks') followed by a concrete list of checks (passivity, reciprocity, energy balance, port symmetry, eigenmode, log errors, spurious modes, convergence), so an agent can infer the domain. But it never states what artifact it operates on (a case dir, results, a config) and does not distinguish itself from siblings like palace_lint_config, palace_lint_rules, palace_doctor, or palace_status.

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 on when to run this versus the numerous sibling lint/doctor/status tools, no prerequisites (e.g. must a simulation have completed first?), and no statement of when it is not appropriate. The list of checks implies a post-run validation context but the agent must guess.

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

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

No annotations are provided, so the description carries the full burden. It does not state whether this is a read-only inspection, whether it probes the environment, what triggers the 'doctor' behavior, or what it returns — only that it concerns available modules and backends.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short clause with no wasted words. It is front-loaded and easy to scan, though it reads as a fragment rather than a complete statement of behavior.

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 zero-parameter, no-output-schema query tool the description is minimally sufficient, but it does not clarify the 'doctor' diagnostic framing or distinguish the result from sibling status/check tools. An agent has enough to guess, not enough to be confident.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There are no arguments whose semantics need explaining, and the description does not need to add parameter detail.

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 fragment conveys the subject matter (available optional modules and Palace backends) but lacks a verb and does not distinguish this from siblings like palace_status or palace_check. The name 'palace_doctor' implies diagnostics, which the description does not confirm or deny, leaving the actual action ambiguous.

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 statement of when to use this tool, when not to, or which sibling to prefer. With 12 sibling tools that plausibly overlap (status, check, spec), the absence of routing guidance is a real gap.

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

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

No annotations are provided, so the description carries the full burden. It adds useful calibration context ('calibrated on ~200 recorded Palace 0.16 runs') and output mode hints (quiet/typical/busy), but it does not state whether the tool is read-only, has side effects, or requires any permissions.

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, information-dense sentence with no fluff, and it front-loads the core purpose. It could be slightly more structured for readability, but 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?

For a tool with 14 undocumented parameters, no output schema, and no annotations, the description is far too sparse. It does not explain how the many optional inputs interact or what the estimation outputs look like, leaving an agent with substantial 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 coverage is 0% for 14 parameters, and the description only loosely maps to three of them ('unknowns', 'config', 'tags'). The remaining parameters (e.g., tets, order, ranks, n_freq, eigen_n, problem, adaptive, calibration, solver_mode, n_excitations, ram_gb) are entirely 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 states a specific verb ('Estimate') and resource ('peak RAM and wall time') and notes both input modes (unknowns or config + tags). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like palace_run or palace_results.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives. It implies estimation before running, but does not say 'use this before palace_run' or provide any conditions/exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only what the list contains and says nothing about permissions, side effects, return format, or how the list is generated, leaving the agent with no behavioral context.

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 with no filler and is front-loaded with the resource name. It is concise, though the parenthetical makes it a slightly fragmentary structure rather than a fully action-oriented statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain what the tool returns, but it only vaguely states the content types (lint rules plus workflow lessons). It does not describe the return shape, ordering, or any usage context, so an agent lacks enough information to understand 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?

The tool has zero parameters and an empty schema, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, a score of 4 is appropriate because the description does not need to compensate for undocumented inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as a gotchas list and clarifies that it contains lint rules plus workflow lessons, which helps distinguish it from sibling tools like palace_lint_rules. However, it lacks a verb and reads more as a label than an action, leaving the operation (e.g., retrieve/list) 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?

No guidance is provided about when to use this tool versus alternatives such as palace_lint_rules or palace_check. There is no mention of prerequisites, filters, or conditions under which the tool is appropriate.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that validation is against the 0.16 schema and that lint rules are run, but it does not say whether the config is mutated, what the failure mode is on invalid config, or how results are surfaced, which matters for a validator with no output 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 tightly packed sentences with the core action front-loaded and the optional geometry hint placed second. No filler and no repetition of the tool name.

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 6-parameter tool with no annotations, no output schema, and no parameter descriptions, the description is too thin. Four parameters are unexplained and the agent gets no sense of the return shape or what happens when validation fails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 6 parameters, so the description must compensate. It adds real meaning for geometry (the *.tags.json file, used for distance/patch checks) and implicitly covers config, but spec, ram_gb, unknowns, and palace_version are left entirely undocumented in both the schema and the description.

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 (validate) plus resource (Palace config), names the schema version (0.16), and enumerates the lint domains checked (solver choice, ports, boundaries, units, AMR, sweeps). It does not explicitly distinguish itself from close siblings like palace_lint_rules or palace_check, so it falls 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?

The description gives one conditional usage hint - pass geometry when distance/patch checks are wanted - which is genuinely useful. However there is no guidance on when to prefer this over palace_check, palace_doctor, or palace_lint_rules, and no prerequisites are 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?

No annotations are provided, so the description carries the full burden. "List" strongly implies a non-mutating read, and it discloses the returned fields, but it says nothing about permissions, caching, or whether the list is exhaustive across workspaces.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the action and the payload are stated immediately and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-arg read-only listing tool the description is nearly sufficient, but terms like "lesson" and "source" are undefined jargon and there is no output schema to clarify them. Slightly more explanation of what a rule record contains would close the 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to compensate for on the parameter side.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("List every lint rule") and even previews the returned fields (lesson, source). It is clearly distinguishable in intent from palace_lint_config, though it does not explicitly contrast itself with that sibling.

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 call this versus palace_lint_config or palace_check, and no prerequisites or conditions are stated. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden, and it does disclose what the tool computes (quality metrics, tet counts, Nedelec unknowns), which is core behavioral content. However, it omits whether it reads a file, requires a valid mesh, is read-only, or how it handles invalid input, leaving meaningful gaps.

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 compact sentence with no filler, front-loading the reported metrics. The telegraphic parenthetical style is efficient, though slightly cryptic for an agent unfamiliar with the domain jargon.

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 simple one-parameter tool with no output schema, the description reasonably covers the return content, and blocking full output details is unnecessary. It still omits the input parameter's meaning and any usage context, leaving the definition adequate but not 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 compensate for the single 'mesh' parameter. Mentioning '.msh file' hints that the parameter is a mesh file reference, but the description does not clarify whether it is a path, an ID, or a required format, so the 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 names a specific resource (a .msh file) and enumerates the exact quantities reported: mesh quality via minSICN and gamma, tetrahedra counts, and Nedelec unknowns. It conveys the essence of a mesh-analysis report, though it is stated as a noun phrase rather than a verb+resource and does not distinguish itself from siblings like palace_mesh_template.

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, no prerequisites, and no mention of alternatives such as palace_mesh_template. An agent must infer its role purely from the reported metrics.

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

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

With no annotations, the description carries the full burden, and it does disclose side effects (writes .msh + .tags.json) and the shape of the return (groups plus a mesh report with exact unknowns per order). It omits permissions, overwrite behavior, and whether existing files are clobbered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense block that front-loads the purpose and then the template signatures. No filler sentences, though the inline parameter lists are cramped and harder to parse than a structured list.

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 helpfully names the return (groups, mesh report, unknowns per order) and the written artifacts. It stops short of explaining how template-specific arguments should be supplied given additionalProperties=true, which is the key gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the top-level schema documents only template/out, but the description compensates by embedding the per-template argument signatures (a,b,d,h; w,h,length,eps_r,h_mesh; etc.) including the ports enum and f_ghz. This meaningfully compensates for the schema gap, though types and defaults remain unspecified.

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 (build and mesh) and resource (template model with Gmsh), and enumerates the three template kinds. An agent can identify the tool's function immediately, though it does not explicitly contrast itself with palace_mesh_report or palace_build_config.

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 by the template enumeration: you use this when you want a predefined model meshed. However, there is no explicit when-to-use vs. the sibling tools (e.g., palace_mesh_report for existing meshes, palace_build_config for config building), so the agent must infer routing.

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?

Since there are no annotations, the description must carry the behavioral burden. It effectively discloses the scope of data handled (the specific file types summarized) and describes a key operational capability (the optional creation and content of the Touchstone output file).

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 highly concise, efficiently combining the primary function (summarize) and the secondary, conditional function (write Touchstone) into one well-structured 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?

Given the complexity of the task (parsing multiple proprietary output formats and handling optional complex outputs), the description is not complete enough. The complete lack of parameter semantics makes it impossible for an agent to correctly formulate the inputs, despite the high-level functional summary.

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%, yet the description focuses entirely on the input data structure (the folder contents) rather than explaining the semantics of the five specific input parameters (e.g., what 'z0' represents or how 'config' is used). It fails to compensate for the severe schema documentation 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 clearly defines the purpose: to summarize a 'Palace output folder.' It also specifies the types of data included (S-parameters, eigenmodes, etc.), distinguishing this results aggregation tool from the other specialized 'palace_' siblings.

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 usage is heavily implied, as it requires an existing 'Palace output folder,' suggesting it must be called after a run. However, it provides clear guidance on one functional aspect: that the Touchstone writing is optional, which guides how the agent should interact with the parameters.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: it blocks until done, it self-refuses under resource pressure, force overrides that guard, and it writes palace.log, time.log, and run_record.json. It still omits timeout behavior, failure/rollback semantics, and side effects on the case directory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with zero filler: the action and blocking nature come first, then the safety guard, then the artifacts produced. Every clause adds information 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?

There is no output schema and no annotations, so the description is the only behavioral source, yet it covers only 3 of 10 parameters and gives no return-value detail beyond the names of log files. For a long-running, resource-gated job launcher this leaves significant 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% across 10 parameters, so the description must compensate and largely does not. It only gives meaning to case_dir, config, and force, leaving cmd, image, ranks, distro, backend, dry_run, and timeout_s completely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run Palace on case_dir/config') plus the scoping constraint that it blocks until completion. This clearly separates it from read-oriented siblings like palace_status, palace_results, and palace_estimate_cost.

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 refusal conditions (oversubscribed job, short RAM) and the 'unless force' escape hatch imply when the tool will and won't execute, which is useful routing context. However, it never says when to prefer this over siblings (e.g., palace_estimate_cost or palace_check first), nor when to use the undocumented dry_run flag.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the core output (a description of the spec plus an example), which is useful, but it does not state return format, whether the operation is read-only, or any other operational trait.

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 a single, front-loaded sentence that states the purpose and the example output. Every word earns its place, with no redundancy or buried context.

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 simple reference tool with no parameters, no annotations, and no output schema, the description is nearly complete: it states what is returned and references the consuming sibling. It could add a note about the return format or read-only nature, but those gaps are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so per the rubric the baseline is 4. There are no parameter semantics to clarify, and the description does not need to compensate for any undocumented inputs.

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 names a specific verb ('Describe') and resource ('compact config spec accepted by palace_build_config'), and it explicitly ties the spec to the sibling tool that consumes it. An agent can distinguish this documentation tool from build_config and lint_config without opening another 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?

The reference to palace_build_config implies this tool is used to learn the config format before building or linting, but there is no explicit when-to-use, when-not-to-use, or alternative selection guidance. The intended usage is inferable but not 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?

With no annotations, the description carries the full burden. It discloses useful behavioral output (job/CPU/RAM state, case progress, start eligibility), which is more than nothing, but it omits permission requirements, whether it mutates state, and any rate or cost considerations for a status probe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the most actionable content ('whether a run may start') placed last but still compact. It avoids filler, though the semicolon-separated fragment list is slightly run-on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description does some of the work of explaining return content, and it covers the main status dimensions. It falls short on parameter documentation and on distinguishing itself from closely related sibling diagnostics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across four parameters, so the description must compensate and only partially does: 'ranks' and the case folder are given meaning, but 'distro' and 'backend' are never mentioned. Half the parameters remain completely opaque to the agent.

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 names the concrete resources it reports on: running jobs, CPU/RAM availability on the Palace host, case-folder progress, and whether a run with a given 'ranks' value can start. That is specific enough for an agent to know what the tool returns. It does not, however, differentiate itself from siblings like palace_check or palace_doctor, which could plausibly overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is named. The phrase 'whether a run with ranks may start now' hints at a pre-run gating use case, but the agent must infer that this is the right tool versus palace_check or palace_doctor.

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