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

Annotations are absent, so the description carries the full burden. It discloses that the tool is read-only (no side effects) and returns rules the server enforces. It does not specify the exact format or content of the rules, but for a reference/documentation tool, this is acceptable. The description adds context beyond the name, which is useful for an agent to know it's a prerequisite.

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 extremely concise and front-loaded: the first sentence states the core purpose, and the second gives an actionable instruction. Every word earns its place. It is appropriately sized for a simple reference tool.

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 tool's simplicity (no parameters, no complex logic), the description is complete for an agent to know when and why to call it. It mentions the server enforces these rules and that reading is required before analysis, which is sufficient. Some might expect more details about the rules themselves, but the tool's output schema likely contains that, so it is not required here.

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 the schema provides no parameter semantics. The description compensates by explaining the tool's purpose as providing rules, which is the only semantic needed. With no parameters, the description adds complete value by clarifying what the tool does, earning a baseline above 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 provides rules for valid NHANES estimation enforced by the server. It uses a specific noun ('rules') and clarifies the context (NHANES estimation). It distinguishes itself from siblings by being a meta-tool about rules rather than a data operation, which is implied but not 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?

The description explicitly instructs to read before analyzing, which signals when to use it (before data analysis or estimation). It does not explicitly name alternative tools that could serve a similar purpose, but given the unique meta-tool nature, alternatives are not obvious. The 'read before analyzing' is clear context.

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

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

With no annotations, the description carries the full burden and does well: it discloses the left-join semantics, DEMO universe requirement, SEQN key, automatic weight selection/rescaling to WT_ANALYSIS, and that weight/design variables are always kept. It omits some behaviors like include_mortality handling and return format, but the core operational behavior is transparent.

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 well-structured: a single front-loaded sentence states the main behavior, followed by concise definitions of the two ambiguous parameters with an example. No filler or redundant wording.

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 join logic, table naming, and weight handling, which are the most critical details. However, it lacks cycle value format, include_mortality semantics, and output shape details, and there is no output schema to fill those gaps. For a non-trivial builder tool this is a meaningful but not fatal omission.

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 explain parameters. It effectively explains 'tables' (base names, no cycle suffix, DEMO always included) and 'variables' (default all, weights always kept), but it does not explain 'cycles' values or the 'include_mortality' flag. It partially compensates for the schema gap but leaves two of four parameters 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?

States a specific verb ('Build') and resource ('analysis-ready dataset') with explicit mechanics: DEMO universe left-joined to requested tables on SEQN for one or more cycles. This clearly differentiates it from sibling tools like list_files, derive_variable, survey_estimate, or export_dataset.

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?

Provides clear context for what the tool does and how to specify tables/variables, including an example table list. However, it does not explicitly state when to use this tool versus alternatives such as derive_variable or export_dataset, so usage guidance is mostly implied rather than directive.

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 transparency burden and does solid work: it discloses boolean-to-0/1 coercion and a precise three-way missing-propagation policy. It doesn't cover side effects such as variable overwrite or persistence, but the core behavior is unusually explicit.

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: main action, concrete example, and the full missing-option semantics. Every sentence adds information and the most important fact is front-loaded.

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 moderate-complexity creation tool, the description covers core invocation semantics and even explains edge-case missing propagation. It omits explicit dataset_id semantics and output/return expectations, but the required fields are otherwise well documented.

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 clearly illustrates name and expression and fully specifies missing's three allowed values. dataset_id is left implicit, though the schema title and required flag make it inferable.

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 opening clause names a specific operation and resource ('Create a variable from an expression over existing columns') and the example disambiguates the intended semantics. It is clear, though it does not explicitly contrast with siblings such as flag_from_long_table or set_missing.

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 when to use it (deriving variables from column expressions) and gives conditional guidance for missing='all' ('for OR-type definitions'). It never names alternatives or says when not to use it, so an agent must infer selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It lists some output content but does not explicitly state that the operation is read-only, whether it has side effects, what permissions are needed, or how warnings are triggered.

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 tight fragment with no filler; every listed item is meaningful and the main output categories are front-loaded. It could be improved by making it a complete sentence and clarifying 'weight choice', 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?

Given the simple schema with one required parameter and no output schema, listing the five output categories is a reasonable starting point. However, the description omits usage guidance, parameter semantics, and any behavioral caveats, so it is not fully complete for an agent deciding when and how to invoke it.

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 only parameter, dataset_id, has no description in the schema and coverage is 0%. The tool description adds no explanation of how to obtain or format dataset_id, although the parameter name is self-explanatory enough to reduce the risk of misuse.

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 the tool's output categories—columns, non-missing counts, weight choice, derived-variable definitions, and warnings—so an agent can infer it produces a dataset-level metadata summary. It lacks an explicit verb and does not distinguish itself from siblings like describe_variable, but the resource and contents are clear.

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

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

The description provides no guidance on when to use this tool versus alternatives such as describe_variable or search_variables. There are no exclusions, prerequisites, or context cues beyond the tool's 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 does well by disclosing both the output contents and the special behavior of flagging refused/don't-know codes. It stops short of explicitly stating that the operation is read-only, but 'describe' strongly implies no side effects.

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 no filler: the first defines the tool's output, the second adds a useful behavioral detail. Every word 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 simple 3-argument tool, the description conveys the core return value and a meaningful behavior. It is incomplete on parameter semantics and does not explain how to source the table/cycle/variable values, but it is adequate as a minimum viable description.

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 mention variable, table, or cycle at all. The agent receives no help interpreting what these three required parameters mean or where their values come from.

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 exactly what the tool returns: a codebook entry (label, question text, target population, value codes) plus an observed distribution. Although it lacks an explicit verb, the resource and scope are specific enough to distinguish it from describe_dataset and search_variables.

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 on when to use this tool versus alternatives like search_variables or describe_dataset. The intended context—inspecting a variable before analysis—is only implied by the tool name and content, 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 disclosure burden. It clearly states that two output artifacts are produced (CSV and provenance sidecar), which is useful, but it omits operational details such as whether existing files are overwritten, whether the dataset is mutated, and what the sidecar contains.

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

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

One sentence, no filler, and the key output detail is front-loaded. The parenthetical variable list earns its place by specifying exactly what 'analytic dataset' means.

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 two-parameter export tool this is close to adequate, but without annotations or an output schema it should have explained filename semantics and the sidecar's role/location. Missing behavioral context prevents a higher score.

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 needed to explain dataset_id and filename. It gives no parameter-specific meaning; the filename parameter and its default are left 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 uses a specific verb and resource: 'Write the analytic dataset ... to CSV plus a provenance sidecar.' It also names the exact variables included, making the scope unmistakable and clearly differentiating it from build_dataset or survey_* 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?

There is no explicit when-to-use or alternative guidance; the intended use as the final export step is implied by the wording and sibling context. It doesn't name exclusions or explain how it relates to build_dataset/describe_dataset.

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 provided, the description carries the full disclosure burden and does so well: it reveals the case-insensitive regex behavior, the ANY-row/ANY-column aggregation logic, and the important missingness rule that people absent from the file are missing rather than 0. These behaviors go well beyond what the tool name or input schema alone would communicate.

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 relevant, and the core behavior is front-loaded before the example. However, it is one long multi-clause sentence with no separation between rule, example, and missingness caveat, so a bit more structure would make it easier to scan.

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

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

For a mutation tool with no annotations and no output schema, the description covers the computation rule, regex behavior, and missingness, which is strong. It is slightly incomplete because it does not explicitly state the role of `dataset_id` and `name` or what the tool returns/updates, but the operation is otherwise unambiguous.

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 explain the parameters. It gives meaningful semantics and an example for `table`, `columns`, and `pattern`, but it never explicitly defines `dataset_id` or `name` (e.g., that `name` is the new variable's name), leaving two of five required parameters to be inferred from parameter titles alone.

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 action and resource: 'Add a per-person 0/1 indicator from a file with several rows per participant.' It fully defines the flag semantics (ANY row, ANY column, regex match) and even differentiates the intended long-table use case from a generic derived-variable operation by naming representative tables such as RXQ_RX and DR1IFF.

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 clearly states the context in which this tool applies: data with several rows per participant, such as prescriptions or food records. It does not explicitly name sibling alternatives or exclusion conditions (e.g., when to use derive_variable instead), so it stops short of a 5.

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

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

With no annotations provided, the description carries the burden of conveying behavior. The verb 'List' implies a safe, read-only operation, and the description further discloses what kind of information is returned (supported cycles, file-name conventions, weight rules). It lacks explicit notes on return format or server-specific limitations, but for a zero-parameter discovery tool the core behavior is transparent.

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, front-loaded sentence with no filler. Every part adds value: the resource, the scope ('this server supports'), and the specific output categories.

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 tool's low complexity (no parameters, no output schema, no annotations), the description covers the essential information an agent needs to invoke it confidently. It could be slightly more explicit about the exact return shape or how the listed cycles map to identifiers used elsewhere, but it is complete enough for correct use.

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 schema coverage is trivially 100%, so the baseline is 4. The description adds meaningful context about what the returned data will contain, even though there are no parameters to document.

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') and a precise resource ('NHANES cycles this server supports'), and it enriches the purpose with the exact output content: file-name conventions and weight rules. This clearly differentiates it from sibling tools like list_files and search_variables.

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 intended use is implied by the description: call this when you need to know which cycles are available and their conventions. However, it does not explicitly mention when not to use it or name any alternative sibling tools, so guidance for tool selection is only implicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is a list (read-only) but does not disclose return format, pagination, error behavior, or whether the list is exhaustive. For a read-only listing tool this is a moderate gap, but the lack of any annotation support makes the description insufficiently transparent.

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 verb and resource, then scopes by cycle and component. It is concise and every word earns its place, though it could be slightly more informative without becoming bloated.

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 2-parameter tool with no output schema and no annotations, the description is thin. It tells the agent what the tool lists and the valid components, but omits cycle format, return shape, and any behavioral details. An agent could call it correctly with reasonable inference, but the description alone does not fully equip the agent.

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 names the two parameters (cycle, component) and gives valid component values, which adds meaning beyond the bare schema. However, it does not explain what a 'cycle' is, what format it should take (e.g., '2017-2018' vs 'P_PRE'), or how the component values map to actual file names. Partial compensation only.

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 ('List') and resource ('data files') with clear scoping by cycle and component, and enumerates the valid component values. It is clear what the tool does, though it does not explicitly differentiate from sibling tools like list_cycles or search_variables.

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 usage context: call this when you need data files for a given cycle and component. It does not explicitly state when to prefer alternatives like search_variables or build_dataset, nor does it provide exclusions or prerequisites. The component enumeration gives some guidance, but no explicit when/when-not 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 no annotations, the description carries the full burden of behavioral disclosure. It explains that matching is regex-based and case-insensitive, and that the search defaults to the 2017-2018 cycle and all components. It does not mention return shape or error behavior, but for a read-only search tool, the key search semantics are disclosed.

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 redundancy. The primary action and scope are front-loaded, followed by the default behavior. Every sentence adds useful 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?

The tool is simple and the description covers the main search behavior and defaults. However, with no output schema and no annotations, the return shape is unspecified, and the limit parameter is not given any semantic context. It is adequate for a basic call but leaves some operational ambiguity.

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 all parameter meaning. It partially explains query (searches variable names/descriptions) and cycles/components (scope with defaults), but it does not explain the limit parameter or the expected string formats for cycles/components. This leaves meaningful gaps for a 4-parameter tool.

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

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

The description uses a specific verb ('Search') with a clear resource ('NHANES variable names/descriptions') and adds implementation detail (regex, case-insensitive, across cycles/components). It is clearly distinguishable from siblings like describe_variable, which targets one variable, and list_cycles/list_files, which list different entities.

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 use: search when you need to find variables by name or description, and it states defaults for cycles and components. It does not explicitly name alternative tools or exclusion cases, but the search-oriented purpose is evident enough to guide selection among the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (recode to missing) but doesn't disclose important behavioral traits: whether the recoding is in-place or returns a new variable, whether it modifies the dataset permanently, whether it overwrites existing missing values, or whether it requires the variable to be numeric. For a mutation tool, this is a significant gap.

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, concise sentence that front-loads the core action and provides useful examples. It earns its place with no wasted words. It could add a bit more context, but for what it says, it's 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?

Given the tool has 3 required parameters, no output schema, and no annotations, the description is too thin. An agent needs to know: does this modify the dataset in place or create a new variable? What happens to the original values? Is there a return value? The examples help, but the lack of behavioral context and parameter explanation makes it incomplete for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'codes' parameter via examples (7, 9, 77, 99) and implies 'variable' is the target variable, but it doesn't explain 'dataset_id' at all. The description adds some meaning for codes but leaves the other two parameters to be inferred from their names. With 0% coverage, this is insufficient.

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 function: recoding sentinel values to missing, with concrete examples (7, 9, 77, 99 for refused/don't know). This is a specific verb ('recode') and resource ('sentinel values'), and it distinguishes itself from sibling tools like derive_variable or describe_variable. However, it doesn't explicitly name a sibling alternative, so it loses one point for not fully differentiating from derive_variable, which could also perform recoding.

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 when to use this tool: when you need to convert sentinel values to missing. It gives examples of typical sentinel values, which helps an agent recognize the use case. However, it doesn't explicitly state when NOT to use it or mention alternatives like derive_variable for more complex recoding. The guidance is adequate but not explicit.

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 behavioral burden and delivers useful detail: Breslow ties, Binder linearized variance, equivalence to known R/SUDAAN functions, and the prerequisite that categorical predictors be dummy-coded first. It does not mention output format or missing-data handling, but the core behavioral constraints are disclosed.

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 dense sentences with no filler. The estimator identity is front-loaded, followed by a practical usage example and a critical prerequisite. 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 is good for constructing a typical call, but the tool is a complex model fitter with no output schema and no description of returned results or how to interpret them. It also does not explicitly distinguish when to use Cox vs. survey_regression, leaving some ambiguity for an autonomous agent.

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 compensates by giving concrete values for time ('PERMTH_INT'/'PERMTH_EXM'), event ('MORTSTAT'), and domain ('ELIGSTAT == 1'), plus a dummy-coding requirement for predictors. dataset_id is left to inference and include_mortality is mentioned outside the schema, but the primary call shape is well illustrated.

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 statistical procedure: survey-weighted Cox proportional hazards modeling, and anchors it to known estimator implementations (SUDAAN SURVIVAL, R svycoxph). This makes the purpose unmistakable and distinguishes it from siblings like survey_regression and survey_frequency.

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 a concrete typical-use scenario for mortality/time-to-event analysis with exact values for time, event, and domain. It does not explicitly name alternatives or state when NOT to use this tool, so it stops 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?

No annotations are provided, so the description carries the full burden. It discloses that the design is NOT subset (out-of-domain records get zero weight), which is a critical behavioral detail. It also mentions Korn-Graubard CIs and NCHS reliability flags for proportions. It does not mention whether the tool is read-only or if it modifies data, but the description strongly implies a read-only estimation operation.

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 purpose. The examples for domain, by, and age_adjust are useful and not redundant. The final sentence about proportions adds important detail. It could be slightly more structured, but it 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?

Given no output schema and no annotations, the description covers the key behavioral aspects: what statistics are supported, how domain works, how by works, and what age_adjust does. It does not describe the return format or error conditions, but for a survey estimation tool, the core usage is well covered. The sibling context suggests this is one of several survey tools, and the description gives enough to distinguish it.

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 domain with an example, by with an example, and age_adjust with a specific value. It does not explain dataset_id or variable, but those are self-evident from the tool name and context. The statistic parameter is not explicitly described, but the first sentence lists mean, proportion, and total, which covers it.

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 ('mean, proportion, or total' via design-based Taylor linearization), and distinguishes itself from siblings like survey_regression and survey_frequency by naming the statistics it produces. It also clarifies the domain behavior (out-of-domain records get zero weight), which is a key differentiator.

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 concrete examples for domain and by parameters, and mentions age_adjust for NCHS standardization. It does not explicitly say when to use this tool instead of survey_regression or survey_frequency, but the statistic list and design-based framing imply the intended use. Sibling names are present, but no explicit exclusions are given.

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 provided, the description carries the full behavioral disclosure burden. It discloses the exact computed outputs, the optional domain/by behavior, and the labels mapping, which is strong for a read-only tabulation tool. It does not discuss missing-value handling or output ordering, but those are minor gaps given the amount of detail present.

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 sentences with no filler. The core behavior and output statistics are front-loaded, and the only extra note is the labels parameter example, which 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?

Given no output schema and no annotations, the description covers the essential output columns, optional parameter behavior, and label formatting. It could be more explicit about when this tool should be chosen over its survey-focused siblings, but it is otherwise sufficient 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 compensate for all five parameters. It clarifies the labels map with a concrete example and explains that domain and by scope/group the output, but dataset_id and variable are left entirely to inference from their names.

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 resource and action: a weighted distribution of a categorical variable in Table 1 style, with explicit output statistics (unweighted n, weighted percent, SE, Korn-Graubard CI). It is clear, but it does not explicitly name or contrast sibling tools such as survey_estimate or describe_variable.

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

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

Usage is implied rather than stated: the description indicates this is for categorical variables and supports domain and optional grouping, but it gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions among the sibling survey tools.

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 non-obvious behavioral traits: survey weighting, design-based standard errors, and the need for dummy-coded predictors. However, it omits what the tool returns, whether it is read-only, and how missing data or survey design are handled.

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 two sentences with no filler. The first sentence states the core behavior and model families, and the second provides the one essential prerequisite, keeping the information front-loaded and scannable.

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 no annotations, no output schema, and 0% parameter description coverage, leaving the description as the only source of guidance. It does not describe the return format, when to select this tool over siblings like survey_cox, or the meaning of the domain parameter, so it is not fully self-sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It usefully explains the 'gaussian'/'binomial' family choices and the dummy-coding requirement for predictors, but it does not clarify outcome, predictors, dataset_id, or domain.

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 what the tool does: survey-weighted linear or logistic regression with design-based standard errors. It also distinguishes the tool from sibling survey tools like survey_frequency and survey_cox by specifying the model families ('gaussian'/'binomial').

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 one explicit prerequisite—dummy-coding categorical predictors with derive_variable—but gives no guidance on when to prefer this tool over alternatives such as survey_estimate, survey_frequency, or survey_cox. Usage context is only implied by the word 'regression'.

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