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 the return shape (status, name, description, rid) and gives a concrete example, but does not mention potential side effects such as duplicate handling, permission requirements, or immutability of existing types. Adequate for a simple add operation, but not deeply 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 with sections for purpose, args, returns, and an example. Every sentence adds value, and the example is a concise concrete illustration of usage.

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 creation tool with an output schema present, the description covers purpose, parameters, return shape, and provides an example. No significant gaps remain, especially given the sibling tool add_asset_type_to_asset clarifies the boundary.

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 input schema provides no descriptions (0% coverage), so the description's Args section is essential. It clearly explains both parameters: 'Name for the asset type' and 'What this asset type represents.' This fully compensates for the missing schema descriptions and includes a usage example.

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 ('Add') with a clear object ('asset type') and target vocabulary ('Asset_Type'). It distinguishes itself from the sibling tool add_asset_type_to_asset, which attaches an existing type to an asset rather than creating a new type.

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 use case is clear: this tool is for registering a new asset type in the vocabulary. No explicit alternatives or when-not cases are provided, but the creation-oriented context is obvious and not easily confused with other 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, the description carries the burden of disclosure. It reveals that type_name must exist in the vocabulary, returns JSON with status and updated types, and allows multiple types. It does not cover error handling or idempotency, but is strong for a simple tool.

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

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

The description is well-structured with summary, args, returns, and an example. It is concise, though the first two sentences convey overlapping information, making it slightly redundant.

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 two-parameter tool, the description is complete: it covers purpose, parameter semantics, return format, and even gives an example. The output schema is mentioned, and the description provides sufficient detail without needing to explain more.

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 descriptions are completely absent (0% coverage), but the description fully compensates by defining asset_rid as 'RID of the asset to modify' and type_name as 'Name of the asset type to add (must exist in Asset_Type vocab)'. This adds essential meaning beyond the parameter 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 clearly states 'Add an asset type to a specific asset' and clarifies it associates an asset with a type from the Asset_Type vocabulary. This distinguishes it from siblings like remove_asset_type_from_asset and add_asset_type.

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 by noting that an asset can have multiple types, implying this operation is used to add additional types. It does not explicitly name alternatives or when-not to use, but the purpose is unambiguous.

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

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

With no annotations, the description carries the behavioral burden. It discloses the action (adds a column), allowed column types, defaults, and return JSON, but does not mention side effects like table locking, failure when the column exists, or required permissions. This is adequate but has clear 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?

The description is well-organized: a one-sentence summary, a compact Args section with per-parameter details, a Returns line, and a concrete example. Every element earns its place, and the structure aids quick parsing.

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 six-parameter surface and absence of annotations, the description is mostly complete: it covers all parameters, defaults, return format, and an example. It does not mention preconditions (e.g., table must exist, column must not already exist) or failure behavior, which would make it fully 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%, but the description fully compensates by explaining every parameter: table_name, column_name, column_type with enumerated allowed values, nullok, default, and comment. It also provides an example showing argument order and keyword usage, making parameter meaning unambiguous.

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

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

The first sentence, 'Add a new column to an existing table,' clearly states the tool's action and target. It does not explicitly mention sibling tools like add_visible_column, but the parameter list (column_type, nullok, default) makes the schema modification intent 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 implies its use for adding a schema-level column to an existing table, but it provides no explicit guidance on when to prefer this tool over alternatives such as create_table or add_visible_column. There is clear context but no exclusions or comparisons.

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. It discloses that the operation creates a relationship, mentions the return format ('JSON with status, parent_rid, child_rid'), and provides an example. It does not cover permissions or reversibility, but for a simple relationship-creation tool the disclosure is adequate.

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 logically structured with sections for summary, common pattern, arguments, returns, and example. Every sentence adds value without redundancy.

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

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

It covers the purpose, parameters, return value, and an example, making it sufficient for a simple two-parameter tool. It omits edge cases or error conditions, but the presence of an output schema and the straightforward nature of the operation keep it reasonably 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?

The schema has 0% description coverage, but the description explicitly defines each parameter: 'parent_rid: RID of the parent dataset' and 'child_rid: RID of the child dataset to nest.' It also gives a concrete example mapping RID values to roles.

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 action: 'Add a dataset as a nested child of another dataset' and 'Creates a parent-child relationship between datasets.' This distinguishes it from sibling tools like list_dataset_parents or add_dataset_members.

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 common pattern ('Complete' parent contains 'Training'/'Testing' children) that makes the intended use case clear. However, it does not explicitly discuss when not to use it or mention alternatives, so it falls short of a 5.

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

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

The description discloses a key side effect: it creates an association table to link records to datasets. However, with no annotations, it lacks detail on idempotency, error conditions, or permission requirements, leaving some behavioral ambiguity.

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, with separate Args/Returns/Example sections. Each part earns its place, including the practical example showing the call and its effect.

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 registration tool, the description covers the operation, its side effect, the return format, and a concrete example. It omits potential prerequisites (e.g., table existence) but remains sufficiently complete given the tool's simplicity.

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 provides no description for table_name (0% coverage), but the tool description compensates with a named parameter description and examples like 'Subject' and 'Image'. This adds meaningful semantics beyond the raw schema.

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

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

The description clearly states the tool registers a domain table as a dataset element type, with a specific verb and resource. It also differentiates from siblings by referencing the follow-up add_dataset_members() and the association table creation.

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 explaining that after registration, records from the table can be added to datasets using add_dataset_members(). This implies the intended workflow and when to use it, though it doesn't explicitly name alternatives or exclusion cases.

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 discloses key side effects: auto-increments minor version, version description stored in history, and requires registered tables. It also clarifies the mutual exclusivity of member_rids and members_by_table, which is a behavioral constraint 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?

The description is well-structured with sections (Args, Returns, Example) and every sentence provides actionable information. The examples at the end effectively illustrate usage without redundancy.

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?

Despite no annotations, the description covers prerequisites, two input forms, mutual exclusivity, return values, and side effects. The presence of an output schema doesn't hurt; the description still provides enough context 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 coverage is 0%, but the description fully explains each parameter with concrete examples (e.g., '{"Subject": ["2-ABC"]}') and clarifies the trade-off between member_rids and members_by_table. This significantly adds meaning beyond the bare schema.

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

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

The first sentence 'Add records as dataset elements' uses a specific verb and resource, and 'Auto-increments minor version' adds a distinct behavioral trait. This clearly distinguishes it from siblings like delete_dataset_members or add_dataset_child.

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 states a prerequisite (records must be from registered tables) and explicitly names alternative tools (add_dataset_element_type, list_dataset_element_types). It also explains when to use each input form, recommending members_by_table when table names are known, and enforces exactly one of the two 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?

Without annotations, the description carries the burden. It discloses the return value (JSON with status, dataset_rid, dataset_types) and gives an example, but does not discuss idempotency, duplicate handling, permissions, or failure modes. This is a moderate disclosure.

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 well-structured with a one-line summary, Args, Returns, and Example. It is concise and every section adds necessary information without filler.

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

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

For a simple two-parameter tool with no annotations, the description provides the core information needed: prerequisites, parameters, return format, and an example. Some edge cases (duplicates, errors) are not covered, so it is slightly below fully 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?

The description fully explains both parameters: dataset_rid is the RID of the dataset and dataset_type is the name of the type to add, which compensates for the 0% schema description coverage. This goes beyond the schema's bare property 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 clearly states the verb 'Adds' and the resource: a 'Dataset_Type vocabulary term' to a dataset. It distinguishes itself from siblings like remove_dataset_type and create_dataset_type_term by specifying that the type must already exist in the vocabulary.

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 clear prerequisite: the type must exist in the Dataset_Type vocabulary, implying that creation of new types is handled elsewhere. However, it does not explicitly name alternative tools or state when not to use it, 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 full burden, and it does well by disclosing batch behavior, provenance handling, accepted value types (term name or asset RID), and return format. It does not cover error conditions or idempotency, but the provided detail is substantial for a mutation tool.

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

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

The description is well-organized with sections for Args, Returns, and Examples. It is slightly long but every section earns its place—the examples clarify usage, and the simple/complex distinction is essential. The structure aids comprehension without redundancy.

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 annotations and no visible output schema in the prompt, the description provides a complete picture: purpose, parameter semantics, return values, and two illustrative examples. It covers both single and batch usage and the provenance option, leaving no major 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 fully compensates. It explains table_name as the table the target records belong to, feature_name as the feature name, entries as a list of dicts with target_rid and value, and execution_rid with its default behavior. This adds significant meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Add feature values to one or more domain objects.' It further clarifies the action as associating feature values with target records, and explicitly distinguishes itself from the sibling tool add_feature_value_record by contrasting simple vs. complex features.

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

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

Explicit guidance is provided on when to use this tool vs. the alternative: 'For simple features... Use this tool' and 'For complex features... Use add_feature_value_record instead.' It also explains the execution_rid provenance behavior (uses active execution when not provided) and batch insertion, giving 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. It discloses dynamic column generation (term_columns, asset_columns, value_columns), the default execution_rid behavior, and the return JSON shape. It doesn't cover idempotency or overwrite semantics, which are important for a write tool, but the core behavior is well explained.

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 longer than average but well-organized with sections (args, returns, example). Each part contributes meaning, though the example is somewhat verbose and could be trimmed. It avoids fluff and maintains structure.

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 dynamic schema, batch operation, and lack of annotations, the description is nearly complete: it includes prerequisite guidance, column type semantics, batch behavior, provenance, and return format. It omits error handling and edge cases, so it is not a 5, but it is highly 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 coverage is 0%, so the description must compensate and does so thoroughly. It explains each parameter: table_name and feature_name with examples, entries as a list of dicts requiring target_rid plus dynamic feature columns, and execution_rid with its default. This goes far beyond the bare schema.

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

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

The description clearly states the tool's function: 'Add feature values with multiple fields to one or more domain objects.' It gives a concrete example and highlights batch insertion, making the purpose distinct. However, it does not explicitly name sibling tools like add_feature_value to draw a contrast, so I cannot give a 5.

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

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

It gives explicit usage context: 'For features with multiple columns... use this tool' and instructs to call lookup_feature first. It also mentions batch insertion. However, it doesn't explicitly state when not to use this tool or name alternatives, so it stops short of full 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?

Without annotations, the description carries the full burden of behavioral disclosure. It explains the parent-child relationship creation, the sequence parameter semantics (None for parallel), and the JSON return format. However, it omits potential constraints or side effects, such as whether a child can have multiple parents or what happens if the relationship already exists.

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

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

The description is well-structured and front-loaded. The opening sentence states the action clearly, followed by relevant use cases, an Args block, Returns, and a concrete example. Every section earns its place with no redundant filler.

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

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

Given the moderate complexity (3 parameters, no annotations), the description is highly complete. It covers the purpose, parameter details, return value, and an example, making it self-contained and easy for an agent to understand and invoke 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?

With 0% schema description coverage, the description fully compensates by defining each argument: parent_execution_rid, child_execution_rid, and sequence. It adds meaningful semantics beyond the schema, such as the sequence being an optional ordering index with None indicating parallel execution.

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 verb and resource: 'Add a child execution to a parent execution' and further explains it 'Creates a parent-child relationship between executions.' This distinguishes it from sibling tools like list_nested_executions, which reads relationships.

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 excellent context for when to use the tool, listing concrete use cases like parameter sweeps, pipelines, and cross-validation. However, it does not explicitly state when NOT to use it or mention alternatives such as list_nested_executions for viewing existing relationships.

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 does mention the return format (JSON with status, name, synonyms list) and gives an example. However, it does not disclose important behaviors such as error handling when the term does not exist, duplicate synonym handling, or idempotency. This is a moderate disclosure but not comprehensive for a mutation tool.

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

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

The description is well-structured with Args, Returns, and Example sections. Every sentence adds value, and the example clarifies usage. It is appropriately sized and front-loaded with 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 simple tool with three parameters and no nested objects, the description covers the purpose, all parameter semantics, return format, and provides an example. It is self-contained and sufficient for an agent to select and invoke the tool correctly, even without annotations.

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 description provides detailed explanations for all three parameters in the Args section, including an example for vocabulary_name. Since schema description coverage is 0%, this fully compensates by adding meaningful semantics beyond the schema's bare type definitions.

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 action ('Add a synonym to an existing vocabulary term') with a specific verb and resource. It distinguishes this tool from siblings like 'remove_synonym' and 'add_term' by focusing on adding an alternative name to an existing term.

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 context that synonyms are alternative names for lookup, which implicitly suggests when this tool is useful. However, it does not explicitly mention when not to use it or name alternative tools (e.g., 'add_term' for new terms, 'remove_synonym' for removing). The usage guidance is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions that term_name must be unique and that the return is a JSON object, but it does not describe what happens on duplicate terms, whether the vocabulary must already exist, or any side effects. This leaves significant behavioral uncertainty.

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 well-organized into Name, Args, Returns, and Example sections. It is concise, with each section adding necessary information and no redundancy. The example is particularly useful for illustrating expected argument usage.

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, the description is fairly complete: it explains purpose, parameters, return format, and shows an example. However, it omits the prerequisite that the target vocabulary must already exist and does not cover error conditions, which are important for an agent to use the tool without failures.

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 input schema has no descriptions (0% coverage), so the description must compensate. It does so thoroughly by explaining each parameter: vocabulary_name with an example, term_name with uniqueness note, description, and synonyms. This fully covers the meaning of all four 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 states 'Add a new term to a vocabulary,' which is a specific verb-resource pair. This distinguishes it from sibling tools like add_synonym (which adds synonyms to existing terms) and create_vocabulary (which creates the vocabulary itself). The example further clarifies the intended operation.

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 through its example and purpose, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The agent must infer that this tool is for creating new terms rather than modifying existing ones.

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 full burden. It discloses that changes are staged until apply_annotations() is called, explains the return value (JSON with updated column list), and describes insertion behavior for position. This is comprehensive 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 well-organized with intro, args, context table, returns, and examples. Every section adds necessary value, and the formatting enhances readability without being verbose.

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 complexity (multiple argument types, context variants, staging behavior), the description covers all aspects: purpose, parameter details, context semantics, examples, and return value. It is fully self-sufficient even without annotations.

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, but the description fully compensates: it explains table_name, context (with a dedicated contexts table), column (three acceptable types with examples), and position (default and behavior when None). This is exemplary 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 clearly states 'Add a column to the visible-columns list for a specific context,' providing a specific verb and resource. It distinguishes from the sibling set_visible_columns by positioning itself as a convenience for adding without replacing the entire list.

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 notes when to use this tool (adding columns without replacing the whole annotation) and mentions staging via apply_annotations(). It does not explicitly name all alternative tools but the contrast with set_visible_columns is strong and enough for an agent to choose correctly.

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 fully carries the behavioral disclosure burden. It discloses the staging behavior ('Changes are staged until apply_annotations() is called'), the return value (JSON with updated foreign key list), the inbound-only constraint for foreign keys, and the optional position behavior. This gives the agent a clear model of side effects and expectations.

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 efficiently structured: a one-sentence summary, then parameter explanations, a compact context table, a critical constraint note, return description, and concrete examples. Each section earns its place, and the most important operational details (staging, inbound-only) are prominently placed.

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 moderate complexity, zero annotations, and zero schema-level parameter descriptions, the description is exceptionally complete. It covers all parameters, valid values, side effects, return format, and practical examples. The presence of a rich description fully compensates for the lack of structured metadata.

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 every parameter: table_name, context (with a table describing supported contexts), foreign_key (list vs dict forms with examples), and position (0-indexed, None appends). This is far richer than the bare schema and fully disambiguates the flexible foreign_key parameter.

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 statement: 'Add a foreign key to the visible-foreign-keys list for a specific context.' It clearly distinguishes this from sibling tools like set_visible_foreign_keys (replace entire annotation) and remove_visible_foreign_key (removal), making the tool's unique role evident.

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 frames this as a 'convenience tool' for adding related tables without replacing the entire visible-foreign-keys annotation, contrasting it with set_visible_foreign_keys. It also notes that changes are staged until apply_annotations() is called, and instructs users to use list_foreign_keys() to find valid inbound foreign keys, providing clear when-to-use and how-to-use 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 of behavioral disclosure. It does state the return format (JSON with status, name, description, rid) and provides an example, offering some visibility into behavior. However, it does not specify side effects (e.g., idempotency, duplicate handling), permission requirements, or constraints, which is a notable gap for a mutating 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 concise and well-structured, using clear sections for Args, Returns, and Example. Every sentence is purposeful, and the example reinforces the usage without redundancy. It is appropriately sized for the tool's low complexity.

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 tool, the description provides the essential information: purpose, parameter definitions, return format, and an example. The presence of an output schema (per context signals) further covers return details. However, it does not address potential edge cases like duplicate type names or whether existing workflows are affected, which would make it fully 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?

The schema provides only names and types, with 0% description coverage. The description compensates fully by defining each parameter ('Name for the new workflow type', 'What this type of workflow does') and includes an example that clarifies expected values. This adds significant meaning beyond the structured schema.

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

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

The description clearly states the action ('Add a new workflow type') and the specific resource ('Workflow_Type vocabulary'), which distinguishes it from broader sibling tools like add_term or create_workflow. However, it does not explicitly contrast with alternatives, so it misses the top score for 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?

No guidance is provided on when to use this tool versus alternatives such as add_term, create_vocabulary, or add_dataset_type. There is no mention of appropriate context prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and description.

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. It clearly explains the commit behavior, lists the staging functions, states the return value, and provides an example. It does not disclose potential side effects like overwriting remote state or error conditions, but it offers a strong behavioral summary for a tool with no parameters.

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 concise and well-structured, with a clear opening sentence, a brief explanation of what is committed, a return type note, and an illustrative example workflow. Every sentence adds value without padding.

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 no parameters and an output schema, the description sufficiently covers purpose, usage, and returns. The workflow example clarifies the typical sequence of operations, making it complete for an agent to invoke 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?

The tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameter meanings, and the example workflow confirms no arguments are required. This aligns with the baseline 4 for zero-parameter tools.

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 specific action 'Apply all staged annotation changes to the catalog' and lists the exact setter functions whose changes are committed. This distinguishes it from sibling tools like apply_catalog_annotations, which likely operate at a different scope.

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 usage context by explaining it commits changes made via the listed setter functions and includes an example workflow. However, it does not explicitly mention alternatives or exclusions, such as when to use apply_catalog_annotations instead, so it earns a 4 rather than 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?

There are no annotations, so the description must carry the behavioral burden. It explains what the tool configures (navigation menus, display settings, bulk upload) and mentions dynamic menu building. However, it omits side-effect details such as whether existing annotations are overwritten, whether the operation is idempotent, or any destructive behavior. This partial transparency is adequate but not complete.

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 long but well-organized into labeled sections (Navigation Bar Structure, Display Settings, Bulk Upload, When to call, Args, Returns, Example workflow). It is appropriately detailed for a complex one-time setup tool, and the structure makes it scannable. Slightly verbose but earned.

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 purpose, detailed behavior, parameter semantics, when to call, and an example workflow. The output schema exists, so return values are not critical to describe. Missing some side-effect context (e.g., overwriting existing annotations) but otherwise comprehensive for a catalog initialization tool.

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%, but the description compensates with an 'Args' section explaining both parameters (navbar_brand_text and head_title) with their meaning and defaults. This provides clear semantic value beyond the bare schema properties.

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 it 'Apply catalog-level annotations to initialize the Chaise web interface' and enumerates specific behaviors (navigation bar, display settings, bulk upload). This distinguishes it from sibling tools like set_table_display or apply_annotations by being catalog-wide and focused on Chaise initialization.

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 includes a 'When to call' section ('After creating the domain schema and all tables') and an example workflow showing the sequence. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to decide.

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 no annotations are provided, the description carries the full burden of behavioral disclosure. It explains the cache status values in detail and outlines what the output contains, providing a clear picture of the tool's behavior. It doesn't mention side effects (likely none), but the level of detail is strong.

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 well-structured with sections for purpose, use case, cache status values, args, and returns. Every sentence contributes meaningful information, and the formatting is clean and scannable. It is detailed without being 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?

Given that annotations are absent and the schema is minimal, the description adequately covers the purpose, usage context, parameters, and output structure. It is complete enough for an agent to understand when and how to invoke the tool successfully.

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 description coverage is 0%, so the description fully compensates by explaining each parameter (dataset_rid, version, exclude_tables) with semantics. It clarifies the optional exclude_tables list and gives a version example, adding significant meaning beyond the raw schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('dataset bag'), and enumerates the exact information returned (size, contents, cache status). It also distinguishes itself from siblings like estimate_bag_size by combining size estimation with cache 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?

The description explicitly mentions when to use the tool: 'Use this to decide whether to cache a bag before running an experiment.' It does not name alternative tools or exclusions, but the context is clear and practical.

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 fully carries the behavioral disclosure burden. It discloses that this is a purely local download with no execution/provenance records, explains the mutual exclusivity of dataset_rid/asset_rid, details behavior of materialize and exclude_tables, and outlines the return format. This is comprehensive for an operation with 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?

The description is well-structured: a clear one-sentence purpose, a brief use-case paragraph, an Args breakdown, and a Returns section. Every sentence adds necessary information for a tool with five parameters; there is no filler or redundancy.

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 annotations, an output schema (though not shown in the prompt), and five parameters covering two distinct modes (dataset vs asset cache), the description covers all necessary aspects: purpose, behavioral effects, parameter semantics, and return structure. It is complete and self-sufficient for an agent to select and invoke 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?

The description includes an 'Args:' section that explains all five parameters, including defaults, mutual exclusivity, version requirement, and when parameters are ignored. Since schema description coverage is 0%, this provides essential meaning beyond the bare schema and fully compensates for the lack of per-parameter 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 opening line 'Download a dataset bag or asset into the local cache without creating an execution' clearly states the action and resource, distinguishing it from execution-creating tools. It also includes the specific use case 'warm the cache before running experiments', which further clarifies intent.

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

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

The description gives explicit context ('Use this to warm the cache before running experiments') and mentions that no execution/provenance records are created, subtly indicating when not to use it. However, it does not explicitly name alternative tools or state direct exclusion criteria beyond 'not both' for parameters, so it stops short of a perfect 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 behavioral disclosure. It adds important context by noting that cancellation is 'best-effort' and that 'long-running operations may not stop immediately,' which helps set expectations. It also outlines the return format, though it doesn't discuss permissions or idempotency.

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 concise and well-structured, with the primary action stated first, followed by args, returns, and a note. Every sentence provides value with no redundancy.

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

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

The tool is simple, has an output schema, and the description includes a behavioral caveat. It could mention what happens if the task is already completed or if cancellation fails, but overall it is sufficiently complete for typical usage.

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 input schema provides only a title and type for task_id, with no description (coverage 0%). The description compensates by explicitly defining task_id as 'The task ID to cancel,' which adds the necessary semantic meaning beyond the schema.

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

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

The description states exactly what the tool does: 'Cancel a pending or running background task.' This uses a specific verb and resource, clearly distinguishing it from sibling tools like list_tasks and get_task_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?

The phrase 'pending or running' provides clear context for when to use the tool, but it does not explicitly mention alternatives or define exclusion criteria. The usage is implied, not contrasted with similar tools like stop_execution.

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 explicitly explains the snapshot timestamp default, the effect of current=True, and the JSON return structure with fields url, rid, and is_snapshot, backed by illustrative examples. This goes beyond a simple definition and fully informs the user.

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 well-organized with Args, Returns, and Examples sections. Each sentence adds meaningful information, and the examples clarify both modes without redundancy. Despite its length, it is concise and purposeful.

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 tool, the description is complete: it covers purpose, parameter semantics, return format, and behavior through examples. The output schema is effectively described via the Returns section, making the tool self-contained and easy to invoke 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?

The schema provides no parameter descriptions (0% coverage), so the description must compensate. It does so thoroughly: rid is defined as the RID of the entity, and current is explained with its default and effect on the URL. The examples further illustrate the parameter values and outcomes.

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 begins with a specific verb and resource: 'Generate a citation URL for a catalog entity.' It further clarifies the scope with examples of entity types and provides examples of the output, clearly distinguishing this tool from sibling tools focused on data manipulation.

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 conditional guidance: 'Use current=True for a link to the live data.' It explains the default snapshot behavior and how to override it. While it doesn't mention alternative tools, none of the siblings serve a citation purpose, so the context is sufficient.

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 full burden, and it delivers exceptionally well. It discloses the three-stage execution process (schema creation, async data copy, FK application), asset handling modes ('none', 'refs', 'full') and their implications, orphan handling strategies, and the fact that it uses export annotations to determine reachability. It also explains potential side effects like 'truncate_oversized' and 'prune_hidden_fkeys'. This goes far beyond typical descriptions.

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 long but appropriately structured with sections for asset handling, orphan handling, and an Args list. There is some redundancy (e.g., asset_mode and orphan_strategy are explained both in dedicated sections and again in the Args list), which adds slight verbosity. However, the information is well-organized and every sentence contributes meaning; the complexity of the tool justifies the length.

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 complexity (19 params, no annotations, and an output schema), the description is remarkably complete. It covers the return format ('JSON with status...'), provides a concrete example, details the multi-stage process, and clarifies all major parameters. The output schema is not shown, but the description summarizes what it returns, which is sufficient for an agent to understand the result shape.

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 19 parameters. The Args section provides a meaningful description for every single parameter, including defaults and examples (e.g., source_hostname 'www.facebase.org', root_rid '3-HXMC'). It explains nuanced behavior like orphan_strategy and asset_mode, adding substantial value beyond the bare schema titles 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 purpose: 'Create an ML workspace by cloning data reachable from a root RID.' It uses a specific verb ('Create') and resource ('ML workspace'), and distinguishes itself from siblings by emphasizing a 'partial catalog clone' and focusing on root-RID reachability. This is unique among the sibling tools, making the purpose unmistakable.

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

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

The description provides clear context on when to use the tool (e.g., cloning data from a project, dataset, or experiment) and explains the high-level workflow (three-stage approach, asset handling modes). It does not explicitly contrast with clone_catalog_async, but the detailed parameter guidance (e.g., orphan_strategy, asset_mode) effectively implies appropriate use cases. No explicit exclusions are given, but the examples and mode explanations serve as practical 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 provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the async behavior, immediate task_id return, use of export annotations to trace reachability, filling uncovered tables, and async copying for performance. It omits auth/failure-mode details but is otherwise strong.

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 long but well-structured: a clear summary, an organized Args block, Returns, and an Example with task-status progression. Every sentence earns its place in supporting a complex 19-parameter async 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?

The tool is complex, but the description covers purpose, usage scenario, parameter semantics, return format, and progress-checking with concrete examples. The output schema exists, and the description complements it rather than repeating structured data.

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%, but the description provides meaningful explanations for all 19 parameters, including defaults, examples for source_hostname and root_rid, and semantics for options like orphan_strategy, asset_mode, and table_concurrency. This fully compensates for the lack of schema-level 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 clearly states it creates an ML workspace by cloning data reachable from a root RID, and explicitly notes it starts in the background and returns a task_id. This specific verb+resource+scope distinguishes it from the sibling clone_catalog and other catalog tools.

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 advises using this tool for large catalogs or cross-server clones that may take several minutes, and instructs checking progress with get_task_status(task_id). It does not name clone_catalog as the alternative for smaller jobs, but the context is clear enough to guide 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 transparently reveals a significant side effect: on connection, an MCP workflow and execution are automatically created, and the workflow type is created if absent. It also explains the auto-detection behavior for schemas. It does not mention authentication, error handling, or failure modes, but the disclosed side effects are critical and well-covered.

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

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

The description is well-structured and front-loaded: the first sentence states the purpose and prerequisite, followed by a brief side-effect note, then Args, Returns, and Examples. Every section earns its place, and there is no verbose filler. Despite being detailed, it remains concise 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?

Given the tool has 4 parameters, no annotations, and no structured output schema, the description is remarkably complete. It covers purpose, prerequisite, side effects, parameter semantics, return format (JSON fields listed), and two distinct examples. There is nothing critical missing for an agent to select and invoke this 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?

The input schema has zero description coverage, but the Args section in the description thoroughly explains each parameter with types, examples, and default behavior. For instance, it clarifies that hostname expects a server hostname with examples, catalog_id is a number, domain_schema is auto-detected if omitted, and default_schema has specific fallback logic. 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 clearly states the tool's purpose: 'Connect to an existing DerivaML catalog.' It specifies the action (connect) and resource (DerivaML catalog), and differentiates from siblings like create_catalog by emphasizing 'existing' and the prerequisite 'Must be called before using other tools.' This gives a specific, unambiguous purpose.

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 states when to use the tool: 'Must be called before using other tools.' It also provides detailed guidance on when to provide domain_schema and default_schema, including auto-detection logic. However, it does not explicitly name alternatives or when-not-to-use cases beyond the prerequisite, so it just misses 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 transparency burden. It discloses that asset tables automatically include specific columns, integrate with executions, and default to the domain schema when none is provided. It also states the return format, covering key behavioral traits beyond a bare 'create' statement.

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 well-structured with a summary, parameter list, return info, and example. Every sentence adds value, and the main purpose is front-loaded. The length is appropriate for the complexity of the 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?

The description is complete for a creation tool: it explains what the tool does, what parameters mean, what is returned, and provides a concrete example. The presence of an output schema reduces the need to detail return values, and the description covers the essential contextual aspects.

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 input schema has no parameter descriptions (0% coverage), but the description fully compensates by explaining each parameter: asset_name, columns, referenced_tables, comment, and schema. It even gives an example, making it clear how to invoke the tool with these arguments.

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 'Create a new asset table for file management with automatic URL/checksum tracking,' which clearly identifies the specific action and resource. It further distinguishes itself from generic table creation by listing automatic columns and integration with executions for provenance.

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: it is for file management with URL/checksum tracking and execution provenance. However, it does not explicitly mention alternatives like the sibling 'create_table' or state when not to use this tool, so it stops short of full exclusion 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 behavioral burden. It discloses key side effects: creates fresh catalog with all ML schema tables, automatically connects, and optionally creates a name alias instead of numeric ID. It does not mention error cases or prerequisites, but for a creation tool it is reasonably 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 well-structured with a clear one-line summary, followed by Args, Returns, and Example sections. Each sentence serves a purpose, and the example adds practical clarity without unnecessary verbosity. It is appropriately sized for a tool with three parameters and a non-trivial return value.

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 presence of an output schema, the description still goes further by outlining the returned JSON fields. It also explains the auto-connect behavior, which is essential context. It lacks explicit failure-mode or permission information, but for a creation tool with a clear output schema, it is largely 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 coverage is 0%, so the description must compensate fully. It does: hostname is explained with examples, project_name is defined as the domain schema name, and catalog_alias gets a detailed explanation of its purpose and an example URL. All three parameters receive meaningful semantic enrichment beyond the bare schema.

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

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

The description opens with a specific verb+resource: 'Create a new DerivaML catalog with all ML schema tables.' It clearly defines the scope (fresh catalog with specific tables) and distinguishes from siblings like clone_catalog or create_catalog_alias by emphasizing the creation of a new catalog with ML schema and automatic connection.

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 to use the tool—creating a new catalog—and explains the automatic connection behavior. However, it does not explicitly compare with alternatives like clone_catalog or connect_catalog, nor state when NOT to use this tool, so it stops short of full alternative 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 of behavioral transparency. It discloses the uniqueness requirement for alias_name, the purpose of aliases, and the return format with an example, which gives good context for expected 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 well-organized with Args, Returns, and Example sections, making it scannable. Every sentence provides useful information, and the example clarifies the expected input/output.

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 purpose, all parameters, the return value, and includes a concrete example, which is sufficient for an agent to select and invoke this tool correctly. The sibling list provides context for related operations, though the description does not need to mention them.

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 provides no descriptions for any of the 5 parameters (0% coverage), but the description compensates with an Args section that explains each parameter, including the format for hostname, the uniqueness constraint for alias_name, and the numeric nature of catalog_id.

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 ('Create an alias for an existing catalog') and explains the benefit of using aliases with a concrete example. It distinguishes from sibling tools like update_catalog_alias and delete_catalog_alias by explicitly focusing on creation.

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 this tool: when a user wants to create a memorable alias for a numeric catalog ID. It includes an example invocation, but does not explicitly mention when not to use it or recommend alternatives such as update_catalog_alias.

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. It discloses that the dataset is created through an execution for provenance, notes that the dataset is empty, and lists the exact return fields (status, rid, description, dataset_types, version, execution_rid). This gives a solid behavioral picture, though it doesn't explore edge cases like failure modes or sync/async 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 well-structured: a clear one-sentence summary, followed by context, usage pointer, args, returns, and an example. Every section earns its place, and the overall length is appropriate for the tool's complexity.

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 tool (3 optional params) and the presence of an output schema, the description is complete. It covers the execution context, the population step, label vocabulary, argument semantics, return fields, and provides an example. There are no major 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 fully explain parameters. It does so with an Args section that clarifies description ('Human-readable description of the dataset's purpose'), dataset_types ('Type labels from Dataset_Type vocabulary' with example), and version ('Initial version string, default 0.1.0'), adding contextual meaning beyond the raw schema.

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

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

The description opens with a specific verb+resource: 'Create a new empty dataset within an execution context.' This clearly distinguishes it from sibling tools like add_dataset_members (which populates) and delete_dataset (which removes), while also mentioning the execution context for provenance.

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 states when to use the tool (to create an empty dataset in an execution) and explicitly directs users to add_dataset_members() for population, providing a clear workflow. It doesn't explicitly state when not to use it, but the context and sibling differentiation are adequate.

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 behavioral disclosure. It reveals that type_name must be unique, explains the purpose of dataset types in ML workflows, and clarifies that the term is created for later assignment, not immediate attachment. It also describes the return JSON structure. It could go further by mentioning reversibility or permissions, but the provided detail is solid.

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 well-structured with an introductory summary, Args, Returns, and Example sections. It is front-loaded with the primary purpose, and every sentence contributes meaning. Despite being longer than a one-liner, the length is justified by the need to explain all parameters and return format without schema support.

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 3 parameters, no annotations, and 0% schema description coverage, the description is complete. It covers what the tool does, when it's used, parameter semantics, return format, and provides a concrete example. It also ties into the broader workflow by referencing add_dataset_type(). No critical information is missing.

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

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

Schema description coverage is 0%, so the description must compensate for the parameters. It does so thoroughly in the Args section: type_name (must be unique), description (purpose), and synonyms (alternative names with an example). The included example call further clarifies parameter usage, fully making up 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 clearly states the tool creates a new dataset type term in the Dataset_Type vocabulary, giving a specific verb and resource. It distinguishes from sibling tools like add_dataset_type (which assigns types) by noting the term 'can then be assigned to datasets using add_dataset_type()'. This is unambiguous and differentiates it from related vocabulary tools.

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 create a dataset type term that will later be assigned via add_dataset_type(). It also mentions common types, giving practical guidance. However, it does not explicitly state when not to use it or directly compare with other creation tools like add_term, so it earns a 4 rather than 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?

No annotations are provided, so the description carries the full burden. It discloses that inputs are recorded as provenance, and explains dry_run behavior (download inputs but skip creating execution records and uploading results). It also mentions the JSON return fields. However, it doesn't disclose potential prerequisites like an active catalog or whether a workflow is auto-created, so it's slightly incomplete.

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 well-structured with clear sections (lifecycle, args, returns, examples) and is front-loaded with the core purpose. While somewhat lengthy, every section adds useful info (especially the examples). It could be slightly trimmed (e.g., the lifecycle block repeats the 'first step' idea), but it remains focused.

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 all 6 parameters, explains lifecycle ordering, provides return value structure, and includes examples. It lacks mention of prerequisites like catalog connection or valid workflow_type values, but given the output schema is partially described and the description is thorough, it is nearly complete for a tool of this 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 must compensate. It does so with an Args section that explains each parameter meaningfully: workflow_name is a descriptive name, workflow_type comes from a vocabulary, dataset_rids and asset_rids are for provenance tracking, and dry_run has a detailed explanation of its side effects. This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Create a new execution to track an ML workflow run with provenance.' It uses a specific verb ('Create') and resource ('execution'), and distinguishes itself from siblings by positioning itself as 'the first step in the execution lifecycle' with references to start_execution and stop_execution.

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 provides a LIFECYCLE list that tells the agent when to call this tool (step 1) and what to do next (start_execution, run workflow, stop_execution). It also explains the dry_run use case for testing without writing to the catalog, giving clear contextual 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 the core behavioral traits: creates a dataset, links it to the execution for provenance, and returns a JSON with dataset_rid and execution_rid. It does not mention permissions or failure modes, but for a create operation, the essential side effect (creating a linked dataset) is stated.

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 structured with an opening statement, a usage hint, and an Args/Returns breakdown. It is easy to scan and contains no fluff. It could be slightly more compact, but the structure supports clarity.

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 (2 params, no nested objects, output schema described in Returns), the description covers all necessary aspects: purpose, usage, parameters, and return value. It does not need to describe return fields in detail because the Returns line lists them. Annotations are absent, but the description is sufficiently complete for this tool.

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

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

Schema coverage is 0%, so the description must compensate. It does: 'description: What this dataset contains' and 'dataset_types: Type labels (e.g., ["Training", "Augmented"])'. This adds meaning beyond the bare titles and defaults, explaining the purpose and format of each parameter.

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: 'Create a new dataset as output from this execution.' It clearly distinguishes from sibling tools like create_dataset (which may not be execution-linked) and create_execution (which creates executions). The phrase 'linked to this execution for provenance' adds a distinctive scope.

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 explicit when-to-use guidance: 'Use this when your workflow produces a new curated collection of data (e.g., augmented training data, filtered results).' It does not explicitly mention alternatives or when NOT to use it, but the given context is clear and helps the agent decide.

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. It discloses that creation results in a new association table and a generated Pydantic model, and that provenance tracking is automatic. This goes beyond a simple 'create' statement and gives the agent a clear picture of side effects, though it omits details like authorization requirements or failure conditions.

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 long but well-structured with sections for purpose, created artifacts, feature types, args, return, and examples. Every sentence adds context—even the Pydantic model explanation is relevant to the tool's behavior. The front-loaded summary ensures the core purpose is immediately clear.

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 six parameters and no annotations, the description covers all parameter semantics, return structure, and importantly clarifies the effects of the operation. The presence of an output schema doesn't reduce the need for the behavioral context supplied here, and the description provides ample examples to guide usage.

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 input schema only lists names and types; the description provides semantic depth: it explains which table the feature attaches to, what 'terms' and 'assets' refer to, and gives a detailed breakdown of the 'metadata' parameter including valid type names and dict keys. This fully compensates for the 0% schema coverage.

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

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

The description opens with 'Create a new feature definition to associate metadata with domain objects,' which clearly specifies the verb ('create') and the resource ('feature definition'). It distinguishes itself from siblings like 'delete_feature' and 'add_feature_value' by focusing on the initial creation act and describing the resulting artifacts.

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 purpose of features in ML data engineering and describes three feature types, which helps the agent understand when to use this tool. However, it does not explicitly contrast with alternative approaches or state when not to use it, 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 full burden. It discloses a process overview (define columns, foreign keys, creation in domain schema, automatic navigation bar update) and states the return format. However, it does not mention error conditions (e.g., duplicate table name) or permission requirements, which would enhance transparency for a mutation tool.

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

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

The description is lengthy but well-organized with clear sections (Process Overview, Args, Returns, Examples). The redundancy of 'domain schema' in the first line and step 3 is minor. Overall, every sentence adds value, though a slight tightening would make it more concise.

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 complexity (5 parameters, nested structures) and the lack of schema descriptions, the description covers all necessary aspects: purpose, process, parameters, return value, and examples. It also notes the automatic navigation bar update, which is a side effect not inferable from the schema. The presence of an output schema further helps, but the description already includes return 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 fully compensates by documenting every parameter in depth. It explains table_name with examples, columns with each subfield and valid types/defaults, foreign_keys with all subfields and defaults, comment, and schema behavior. This is far beyond what the minimal schema provides.

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 'Create a new table in the domain schema' and immediately distinguishes itself from create_asset_table ('not an asset table'). It names the specific sibling tool to use for asset tables, making the tool's scope 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?

Explicit guidance is provided: 'For tables that store files with automatic URL/checksum tracking, use create_asset_table instead.' It also gives detailed examples of common use cases, making it clear when and how to use this tool vs. alternatives.

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. It discloses the return format (JSON with status, name, schema, comment) and the default schema behavior, which is helpful. However, it does not mention permissions, side effects (e.g., overwriting existing tables), failure modes, or any irreversible actions, leaving some behavioral uncertainty for a mutation tool.

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

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

The description is well-structured and concise: a one-sentence purpose, a bulleted Args section, a Returns section, and an example. Every part adds value, and the format is easily scannable for an agent.

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 purpose, parameters, return value, and provides an example, making it fairly complete for a create-vocabulary tool. It lacks edge-case handling (e.g., duplicate names, null schema implications), but given the moderate complexity and presence of return format, it is sufficiently complete for typical usage.

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 description explicitly documents all three parameters: vocabulary_name, comment, and schema, providing meaning beyond the bare schema definitions. It clarifies defaults and purpose (e.g., 'default: domain schema'), compensating fully for the 0% schema description 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 action: 'Create a new vocabulary table for storing controlled terms.' This clearly identifies the tool's purpose and distinguishes it from siblings like create_table or create_catalog. The verb-resource pair is explicit and unique.

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 by its specific purpose (creating vocabulary tables) and provides an example, but it does not explicitly contrast with alternatives like create_table or state when not to use it. There is no direct guidance on choosing this over sibling tools, so usage is implied rather than explicitly directed.

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. It discloses that the tool creates and registers, and describes the return structure. However, it does not mention side effects, permissions, or potential errors, leaving gaps in behavioral transparency.

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 well-structured with Args, Returns, and Example sections. It's front-loaded with the core statement and every sentence provides value. Slightly verbose due to example, but not wasteful.

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 create tool, the description covers purpose, parameters, return format, and an example. It doesn't discuss usage alternatives or edge cases, but given the tool's simplicity and the presence of an output schema, it is sufficiently 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?

The schema provides no descriptions (0% coverage), but the description compensates by adding 'Display name' for name, 'Type from Workflow_Type vocabulary' with examples for workflow_type, and a purpose for description. This adds meaningful context beyond the titles.

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 'Create and register a new workflow definition', using a specific verb and resource. It distinguishes itself from sibling tools like set_workflow_description or add_workflow_type by focusing on the creation/registration aspect.

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 implied: you'd use this to create a workflow. However, there is no explicit guidance on when to use it vs alternatives, no exclusions, and no mention of prerequisites. This is adequate but basic.

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 fully bears the burden of disclosing behavior. It explicitly states that the operation is permanent, deletes 'all its data,' and cannot be undone, which are critical behavioral traits. It also mentions the return value, covering the basic behavioral expectations.

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 most important warning, followed by args and returns in a clean list. Every sentence contributes essential information, with no filler or repetition.

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 delete operation with an output schema present, the description covers the key elements: purpose, destructive scope, irreversibility, parameter definitions, and return type. It is sufficiently complete for an agent to safely invoke the operation.

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 zero description coverage, so the description compensates by explaining 'hostname' as 'Server hostname' and 'catalog_id' as 'ID of the catalog to delete.' While the hostname explanation is somewhat generic, it adds value beyond the bare schema titles and clarifies each parameter's role.

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 'PERMANENTLY DELETE a catalog and all its data,' which uses a specific verb and resource, and the warning 'Cannot be undone' distinguishes it from other catalog operations. This clearly separates it from sibling tools like delete_catalog_alias or cancel_task.

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 by stating the irreversible, destructive nature of the operation, implying it should only be used when permanent deletion is intended. However, it does not explicitly mention alternative tools for deleting catalog aliases or other scoped deletions, so it lacks explicit 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 transparency burden. It adds valuable behavioral context by stating that the target catalog is not deleted, and it discloses the return format as 'JSON with deletion status'. This goes beyond a bare mutation description, though it lacks details on idempotency, permissions, or error cases, which prevents a higher score.

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 well-structured with a clear statement, Args section, Returns section, and Example. It is concise and front-loaded, with every sentence providing necessary information without redundancy.

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 complete for this simple delete operation: it states the action, key side-effect, parameters, return format, and a concrete example. The existing output schema reduces the need to detail return values further, and the tool's simplicity means no additional context is required.

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 schema description coverage at 0%, the description compensates by providing semantic definitions for both parameters: hostname as 'Server hostname' and alias_name as 'The alias identifier to delete'. This adds meaning beyond the minimal schema titles, and the example reinforces usage. It does not include type constraints or further detail, but it meets the compensation need.

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 specific action: 'Delete a catalog alias', and immediately clarifies the scope by noting 'The target catalog is NOT deleted'. This effectively distinguishes the tool from the sibling 'delete_catalog', satisfying both verb+resource clarity and 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 description provides clear context that this tool is for deleting an alias while preserving the underlying catalog, which implies when to use it. However, it does not explicitly name alternatives such as 'delete_catalog' or state conditions when not to use it, so it falls short of full alternative 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 bears the full burden. It transparently explains that the delete is a soft mark that hides from queries while preserving data, and that recurse affects child datasets. It also covers the return structure, which is useful; however, it omits permissions or error conditions.

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 efficiently structured, with a one-line summary followed by essential behavioral details and an Args/Returns section. No redundant sentences are present, and key information 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 two-parameter tool with a described output, the description covers purpose, behavior, parameters, and return value. It is complete even without annotations, and the recurse behavior is clearly explained.

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 fully compensates by explaining both dataset_rid and recurse in plain language, including the effect of recurse on nested datasets. The schema only lists types, so this added meaning is essential.

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 phrase 'Soft-delete a dataset (marks deleted but preserves data)' clearly identifies the action and resource. It distinguishes this from other delete operations like delete_catalog, and the 'soft' qualifier differentiates it from potential hard-delete 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 description provides context on when to use the tool: when you want to hide data without destroying it, and it mentions the recurse option for nested datasets. It does not explicitly list alternatives or exclusions, but the behavioral context is sufficient for an agent to select it appropriately.

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

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

With no annotations, the description carries the full burden and discloses key behavioral traits: auto-increments minor version, records themselves are not deleted, and the return payload includes status, removed_count, and dataset_rid. This gives a solid understanding of side effects, though permissions or error behavior are not covered.

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

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

The description is well-structured with a summary, behavioral notes, Args, Returns, and Example. It loses a point because the minor version auto-increment is mentioned twice, which is redundant but not severely wasteful.

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 two-parameter tool with no annotations and an output schema, the description covers the essential operation, side effects, and return format, plus an example. It omits edge cases and prerequisites, but given the simple scope, it is sufficiently complete for correct selection and 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 does so fully with a dedicated Args section that explains dataset_rid and member_rids clearly and provides an example of the expected list format. This leaves no ambiguity about parameter meaning.

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