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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states that execution stops at the first failure, that atomic rollback is the default, and that dry_run=true returns the plan. This covers critical failure and preview behavior, though it omits details like permission requirements or whether changes persist to disk.

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 two sentences with no filler. The purpose is front-loaded, the operations list is compact, and behavioral notes are appended efficiently. It is well-structured and easy to parse.

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

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

Given the complexity of a batch patch tool with many operation types and no output schema, the description covers the essential aspects: the operation list, atomicity, failure handling, and dry-run preview. It does not detail the response format or prerequisites like model availability, but the core information for correct invocation is present.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'operations' parameter format and lists valid op values, and explains the effect of dry_run. However, it does not clarify the meaning or format of model_id, and atomic is only mentioned in passing, not fully defined as a 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 clearly states the verb 'apply' and the resource 'model', and enumerates a specific list of supported patch operations, which distinguishes it from individual sibling tools like create_table or drop_column. It conveys the batch nature of the operation effectively.

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 a batch use case through the ordered list and atomic rollback, but it does not explicitly state when to prefer this tool over calling individual sibling tools, nor does it mention prerequisites such as the model being open. The guidance is implicit rather than explicit.

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

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

With no annotations available, the description carries the disclosure burden. It discloses a non-obvious side effect: for file-backed models, the current file is saved and backed up so rollback can restore the exact pre-transaction state. It also signals that a txn_id is returned. It stops short of clarifying auto_save behavior for non-file-backed models, but the core transactional behavior is transparent.

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

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

Three concise sentences cover action, behavioral note, and next step. There is no filler, and the key guidance is front-loaded before the side-effect explanation.

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 transaction lifecycle, mentions the returned txn_id despite no output schema, and explains rollback behavior. However, with no annotations and an unexplained auto_save parameter, an agent still lacks enough detail to fully understand all call configuration paths and non-file-backed behavior.

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

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

Schema description coverage is 0%, and the description does not explain either model_id or auto_save. model_id is partly inferable from the tool context, but the auto_save boolean's meaning and effect on transaction behavior remains undocumented. An agent selecting this tool cannot confidently configure the optional 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 names a specific operation ('Start a transaction'), a resource scope ('models'), and the workflow position ('before a batch of modifications'). It distinguishes itself from commit_transaction and rollback_transaction by explicitly instructing the agent to pass the returned txn_id to those sibling 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?

It provides an explicit condition for use ('before a batch of modifications') and the follow-up protocol ('Pass the returned txn_id to commit_transaction / rollback_transaction'). It does not include a when-not-to-use case, but the intended transactional context is clear enough.

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 behavioral disclosure. It reveals that rules with unknown types are not silently ignored, which is a key behavior. It also lists return categories (passed/errors/warnings/violations), but does not detail error handling, side effects, or operational requirements. Given the absence of annotations, this is adequate but not rich.

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 moderately concise, packing essential information about rules handling in a single paragraph. It starts with the core purpose and then details the rules parameter. It could be slightly more structured but is free of fluff and front-loads the main action.

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 (array of rule types, unknown-type handling) and the sparse schema (0% coverage), the description covers most necessary ground: it explains the rules structure, type handling, and return categories. It misses only the model_id semantics, but overall is sufficiently complete 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?

Since schema description coverage is 0%, the description must fully explain parameters. It describes 'rules' in detail, including the structure and types. However, 'model_id' is only defined by its title; the description does not explain what a model_id is or how it relates to the model being checked. This is a notable gap.

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

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

The description clearly states the tool's purpose: checking a model against user-defined design rules. It specifies the resource (a model) and the action (check), which distinguishes it from validation tools. However, it doesn't directly contrast with siblings like validate_model, so it gets a 4 rather than a 5.

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

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

The description elaborates on the rules parameter, explaining the types and how unknown types are handled ('reported in skipped'). This gives context on how to construct the rules. However, it doesn't explicitly discuss when to use this tool versus other validation or inspection tools, which would require 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, the description carries the full burden of behavioral disclosure. It discloses the key behavior of the save parameter (save=true saves to file before closing), implying unsaved changes are lost otherwise. However, it doesn't mention error conditions, side effects, or what happens if the model isn't open. It adds some value beyond the schema but misses other behavioral aspects.

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

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

The description is extremely concise: two sentences with no wasted words. It front-loads the primary purpose and immediately adds the critical save option. Every sentence contributes 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?

For a simple operation with only two parameters and no output schema, the description covers the essential behavior (closing and save option). It lacks explicit error handling or side-effect notes, but given the low complexity and that the save behavior is addressed, it is largely complete. A 4 is appropriate because it could mention what happens if the model is not open, but it is not severely incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the save parameter ('save=true saves to its file before closing'), adding meaning beyond the bare schema. However, it does not explain model_id beyond what the schema already says ('Model Id'), leaving its role implicit. Partial compensation but incomplete.

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: closing a model in PowerDesigner, with a specific resource (model). It distinguishes from siblings like open_model, create_model, save_model by focusing on the close operation. However, it doesn't explicitly mention that it operates on an already-open model, which could be implied but is not stated, so a small gap in 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., model must be open), nor does it contrast with save_model or open_model. There is no exclusionary guidance, so the agent is left to infer usage 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?

No annotations are provided, so the description carries the burden. It discloses the key behavioral effect: changes are kept and the backup is discarded. However, it does not mention whether the transaction must be active, what happens if the txn_id is invalid, or whether this is destructive to the backup. The phrase 'discards the backup' hints at destructiveness, but the description could be more explicit about the irreversible nature.

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

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

The description is a single, concise sentence that front-loads the action and its effect. Every word earns its place. It is appropriately sized for a simple one-parameter 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?

For a simple one-parameter tool, the description is mostly adequate. It explains the action and the key effect. However, it lacks context about the transaction lifecycle: how to obtain txn_id, whether the transaction must be active, and what happens to the backup after commit. Given no annotations and no output schema, a bit more context would be helpful.

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. The description does not explain the txn_id parameter beyond its name and type in the schema. It does not state where to find the txn_id (e.g., from begin_transaction) or what format it should be. The description adds no parameter-level 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 a specific verb ('Commit') and resource ('a transaction'), and clarifies the effect: 'keeps all changes and discards the backup.' This distinguishes it from rollback_transaction, which would revert changes. It could be slightly more explicit about the transaction lifecycle, but the core purpose is 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 usage: commit when you want to keep changes and discard the backup. It does not explicitly state when to use this vs rollback_transaction, but the contrast is strongly implied by 'keeps all changes and discards the backup.' No explicit exclusions or prerequisites are given.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It clearly says the operation is a structural comparison and lists the compared elements, and 'compare' implies a read-only operation. However, it does not explicitly state that models are not modified, nor does it describe what happens when one of the given model IDs is not open or invalid.

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

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

The description is a single well-focused sentence that front-loads the verb and resource, then uses a colon to list the comparison categories. Every element adds information, with no filler or repetition of the schema.

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 comparison categories are enumerated, which gives a strong hint about the expected output content. However, with no output schema and no annotations, the actual return format is unspecified — an agent cannot know whether the result is a structured diff object, a list of changes, or a summary. Given the low parameter count, the description is usable but not 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 parameter names and titles with 0% description coverage, so the description must compensate. It maps the two parameters to 'two open models', indicating that model_id_a and model_id_b are model identifiers and that the models must already be open. It does not explain how to obtain these IDs (e.g., via list_open_models) or the expected ID format, leaving some ambiguity.

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 specifies a clear verb ('compare') and resource ('two open models'), then enumerates exactly what is compared: added/removed/modified tables, columns per table, references, and domains. This level of specificity distinguishes it from siblings like inspect_schema or get_model_info, which focus on a single model rather than a diff between two.

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 'two open models' implies the use case — use this when you need to diff the structure of two models. However, there is no explicit guidance on when not to use it or which sibling (e.g., model_snapshot, inspect_schema) might be a better alternative for single-model inspection. Usage is implied, not stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions the PowerDesigner native conversion fallback and return value, but it does not say whether the source model is modified, whether the new LDM is saved or opened, whether the operation is reversible, or what happens on failure.

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 front-loaded with the core purpose. The fallback mapping sentence adds some implementation context, though it is not strictly necessary, and the return-value sentence is useful.

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 conversion tool with no annotations and no output schema, the description is too sparse. It omits key operational context such as side effects on the source model, how the 'new model info' is structured, whether the new model is persisted, and how this compares to the CDM-to-PDM conversion path.

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 clarify the model_id parameter, but it never explicitly states that model_id is the CDM model to convert, its required format, or any constraints. The parameter name is self-explanatory to some degree, but the description adds no semantic value 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 a clear action ('Convert'), a specific source resource ('CDM model'), and a distinct target ('LDM'). This differentiates it from sibling tools like convert_cdm_to_pdm and convert_ldm_to_pdm based on target model 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?

No guidance is given about when to prefer this tool over alternatives, such as convert_cdm_to_pdm or convert_ldm_to_pdm. The description implies the target LDM but does not state conditions, prerequisites, or 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?

With no annotations, the description carries the behavioral disclosure burden. It does add meaningful context by revealing a two-step strategy: native conversion first, then structured mapping as fallback. But it does not disclose whether the conversion mutates the source model, creates a new model, or what output/result the agent should expect.

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 very short and front-loaded. The core action is stated first, the optional parameter is parenthesized, and the fallback strategy is a single second sentence. Every phrase earns its place.

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

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

The tool has no output schema and no annotations, so the description must cover conversion behavior and return semantics. It explains the basic purpose and dbms input, but omits whether the conversion is in-place, whether a new model is produced, and what a successful conversion returns. This is a significant gap for a conversion 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%, so the description must compensate for both parameters. It explains dbms with an example, but it never describes model_id, which is the only required parameter. The name alone is suggestive, but not enough for an agent to know what the model ID refers to.

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

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

The description states a specific verb ('Convert') and resource ('a CDM model to a PDM'), and it clearly distinguishes this tool from siblings like convert_ldm_to_pdm and convert_cdm_to_ldm by naming the source and target model types. The optional dbms note adds useful 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 implies the obvious use case from the tool name and gives one explicit usage hint: optionally pass a dbms value such as 'MySQL 5.0'. However, it does not explain when to prefer this tool over sibling conversion tools or when the fallback path would apply.

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 full responsibility for behavioral disclosure. It reveals a fallback strategy but does not state whether the operation is in-place, returns a new model, has side effects, or requires the model to be open. It also does not mention error behavior or permissions.

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

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

Two concise sentences, with the core purpose front-loaded. The fallback detail is relevant but could be more precisely phrased; overall, it is efficient and free of 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?

There is no output schema, yet the description does not explain what the conversion returns (e.g., a new model ID, a confirmation) or whether the original model is modified. It also omits prerequisites such as the model being open, and does not clarify the acronyms or potential failure modes. For a conversion operation with no annotations, this is insufficient.

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 adds meaning to dbms by noting it is optional, but does not explain accepted values or the default behavior. model_id is only labeled by its name and is not elaborated, though its purpose is fairly self-evident. The description only partially fills the semantic gap.

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

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

The description states a clear action ('Convert an LDM model to a PDM') with a specific resource and target, and mentions the optional dbms parameter. It is distinct from sibling conversion tools (CDM to PDM, CDM to LDM), though it does not explicitly clarify the acronyms or contrast with these alternatives.

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

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

No guidance is given on when to use this tool versus convert_cdm_to_ldm or convert_cdm_to_pdm. The phrase 'Native conversion first, structured mapping as fallback' describes the internal algorithm, not the usage context or conditions for selecting this tool.

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

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

No annotations are provided, so the description carries the full burden. It mentions support for dry_run, which is a behavioral detail, but it does not disclose other important behaviors such as transactionality, whether the operation is reversible, what happens if the column already exists, or any error conditions. For a mutation tool with 13 parameters, this is a significant gap.

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

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

The description is concise at two sentences, front-loading the purpose. The list of supported properties is dense but useful given the lack of schema descriptions. It avoids unnecessary fluff and is well-structured. The only minor inefficiency is the redundant mention of 'description' when it's not in the schema, but overall it is appropriately sized.

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

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

Given the complexity (13 parameters, no output schema, no annotations), the description is incomplete. It does not cover error handling, return value, prerequisites, interaction with transactions (siblings like begin_transaction exist), or how dry_run behaves in practice. An agent calling this tool would need to guess about these aspects, making the description insufficient for full context.

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 lists and explains many parameters (name, code, data_type with examples, length, precision, mandatory, default_value, comment, domain, primary), providing meaningful semantics beyond the bare schema. However, it omits explanation for model_id and table_ref (though these are self-evident) and incorrectly mentions a 'description' property that does not exist in the schema, which could confuse. Overall, it adds substantial value but has minor gaps.

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 column to a table.' This is a specific verb+resource, and it distinguishes itself from sibling tools like update_column, rename_column, and delete_column by focusing on creation. The supported properties list further clarifies scope without ambiguity.

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 for creating a new column, and the presence of sibling tools like update_column and delete_column makes the intent clear. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites (e.g., model must be open). The guidance is implied rather than explicit.

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

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

With no annotations, the description carries full behavioral burden and does well: it discloses that dry_run=true returns the execution plan without modifying the model, that atomic=true defaults to true, and that failures roll back the model. It also explains how primary keys are derived. This is genuinely useful behavioral context beyond 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 core purpose is front-loaded in the first sentence, and the rest compresses a lot of schema spec detail into a compact inline JSON sketch. It is dense but efficient; no 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 complex tool with nested objects and no output schema, the description covers the spec shape, atomic behavior, dry-run behavior, and primary-key derivation. A minor gap is that it doesn't describe what the normal (non-dry-run) call returns beyond implying side effects, but the provided detail is sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It provides a detailed JSON spec structure for tables, columns, relationships, domains, and indexes, and clarifies the dry_run and atomic flags. model_id is not elaborated, but its meaning is largely self-evident from the parameter name and title.

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

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

States a specific verb ('Create') and resource ('whole database schema') and explicitly frames it as one call from a JSON spec. This clearly distinguishes it from granular siblings like create_table and create_column.

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 'Create a whole database schema in one call' implies a batch-use scenario, but the description never explicitly says when to prefer this over the granular create_table/create_column tools or when not to use it. Usage context 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 burden of behavioral disclosure. It mentions 'Supports dry_run,' which is a useful non-destructive testing behavior, but it does not disclose permissions, side effects, idempotency, or error 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 compact and front-loaded with the core purpose. The example is concrete and useful, and the dry_run note is relevant, though the sentence order could place the dry_run note more prominently.

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 7 parameters, no output schema, and no annotations, the description is incomplete for reliably calling the tool. It omits the purpose of required parameters like model_id and table_ref, and lacks information about return values or failure modes.

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 7 parameters. It provides an example for 'columns' and 'name' and mentions 'dry_run', but it does not explain required parameters 'model_id' and 'table_ref', nor 'unique' and 'comment' semantics.

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

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

The description clearly states the tool's function: 'Create an index on a table' and enumerates supported types (normal, unique, composite). The resource 'index' distinguishes it from sibling create tools like create_table, create_column, and create_primary_key, though it does not explicitly name alternatives.

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 purpose statement implies the tool is for creating indexes, which gives basic usage context. However, it offers no guidance on when to choose this over create_primary_key or create_reference, nor any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates an 'empty' model and returns info including model_id, but does not mention whether the model is persisted, whether it participates in transactions (siblings like begin_transaction exist), or any side effects like overwriting existing models. This is a significant gap for a creation operation, leaving agents uncertain about the model's lifecycle or state.

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

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

The description is a single, well-structured sentence that front-loads the core action and parameter constraints. There is no redundant phrasing or repetition of the tool name. It efficiently conveys the essential information without excess, making it easy for an agent to parse quickly.

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

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

There is no output schema, so the description must explain the return value; it does mention 'Returns the new model info including its model_id,' which is helpful. However, it does not clarify what 'code' means, whether the model is saved to disk, or how this interacts with transactions (given the transaction siblings). These gaps make the definition incomplete for an agent to confidently invoke the tool without making assumptions.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of 'kind' and 'dbms' (including defaults and examples), but provides no explanation for 'code' or 'name'. While 'name' is intuitively the model's name, 'code' is left unexplained. This partial coverage helps but does not fully clarify all parameters, so a score of 3 reflects the partial compensation.

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 action ('create a new empty model') with a specific resource (model) and explicitly enumerates the valid values for 'kind' (PDM, CDM, LDM). It also clarifies the optional 'dbms' for PDM. This unambiguously distinguishes it from siblings like open_model, delete_table, or convert_cdm_to_pdm, which operate on existing models or other objects.

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 the tool is for creating a new model, and the context is clear from the name and sibling list. However, it does not explicitly state when to use this versus an alternative (e.g., 'use open_model to load an existing model'). It gives parameter-level guidance for dbms but no exclusionary conditions. The guidance is adequate but not explicit about alternatives, so a score of 4 is appropriate.

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

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

With no annotations provided, the description must disclose behavioral traits on its own. It does state that existing PK membership is cleared and that dry_run is supported, which are important. However, it omits details such as potential side effects on indexes or transactions, and does not mention permissions or reversibility.

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 two sentences with a clear example, front-loaded with the purpose and key behavioral note. Every word earns its place with no 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 tool with six parameters and no output schema, the description is incomplete. It lacks details on return values, the exact format of model_id and table_ref, the roles of code and name, and a precise definition of dry_run. It also fails to differentiate from set_primary_key, leaving ambiguity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'columns' parameter via the example and 'column codes', but leaves model_id, table_ref, code, name, and dry_run unexplained. This is a significant gap for a tool with six 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 a specific action: create or replace the primary key of a table from column codes, with a concrete example. It is unambiguous about the resource and verb, but it does not explicitly differentiate from the sibling tool set_primary_key, which overlaps in 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?

No guidance is given on when to use this tool versus set_primary_key or remove_primary_key. There is no mention of conditions, alternatives, or exclusions, leaving the agent without selection criteria.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains the auto-creation of FK columns when parent_columns/child_columns are omitted, mentions the default update_key=true, gives cardinality examples, and notes dry_run support. This goes beyond a simple 'creates a reference' and reveals meaningful side effects and options.

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 three sentences, each earning its place. The first sentence states the core purpose, the second explains the auto-creation behavior, and the third covers cardinality and dry_run. It is front-loaded with the most critical information and contains no fluff.

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 11 parameters, no annotations, and no output schema, the description covers the essential behavioral aspects: relationship type, auto-creation logic, cardinality, and dry_run. It does not describe return values or error handling, and it omits some parameter details, but it provides enough for an agent to make a correct primary call. It is not exhaustive but is reasonably complete for the core use case.

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 adds meaning for several key parameters: parent_columns/child_columns (omission behavior), cardinality (examples), dry_run (support), and update_key (default true). However, it does not explain model_id, parent_table, child_table, code, name, or comment, though these are partially self-explanatory. The description provides partial but not comprehensive parameter semantics.

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

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

The description clearly states the tool's action: 'Create a foreign-key reference between two PDM tables (1:N from parent to child).' It specifies the verb, resource, and relationship type, making it distinct from sibling tools like update_reference, delete_reference, and list_references. The direction (parent to child) and cardinality are also clarified.

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 this tool—to create a reference—and implicitly distinguishes it from updating or deleting references. It explains the auto-creation behavior when columns are omitted, which is a key usage condition. However, it does not explicitly name alternative tools or provide exclusion criteria, 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 must carry the full transparency burden. It discloses that the tool creates a table/entity, can optionally create columns, and supports dry_run. However, it omits operational behaviors like whether it requires an open model, what happens on success (return value), or any side effects beyond creation. The description adds some context but lacks depth 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 two succinct sentences, front-loaded with the primary purpose. It avoids redundancy, uses precise terminology, and includes the key optional feature inline. Every word earns its place, making it highly efficient.

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

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

For a tool with 6 parameters, no output schema, and no annotations, the description leaves out critical contextual details such as prerequisites (e.g., the model must exist), the expected return value, and whether the operation modifies the model in memory. While it mentions dry_run and columns, it does not address how an agent should handle errors or confirm success. The description is adequate but not fully complete for a mutation 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%, so the description must compensate for undocumented parameters. It only clarifies the 'columns' and 'dry_run' parameters, leaving 'model_id', 'name', 'code', and 'comment' unexplained. These are not self-evident, especially 'model_id', which is required. The description provides minimal value for the majority of 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 the verb 'Create' and the resource 'a table (PDM) or entity (CDM/LDM)'. It distinguishes itself from create_column by referencing the shape of its column spec, and mentions optional inline columns, which sets it apart from other create tools. The purpose is unambiguous and specific.

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

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

The description implies usage context (creating a table/entity, optionally with columns) but does not explicitly state when to use this tool versus alternatives such as create_column or create_model. It mentions 'Optionally pass an inline columns array' which hints at a usage option, but there is no clear exclusion or alternative routing. Usage is implied rather than prescribed.

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 labels the operation as destructive and recommends dry_run first, which is a meaningful behavioral trait. However, it does not mention side effects, reversibility, permission requirements, or consequences of deleting a column that is in use, so the disclosure is minimal but present.

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

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

The description is exactly two sentences with no filler. The purpose is front-loaded ('Delete a column from a table') and the destructive warning follows immediately. Every word earns its place, making it highly efficient.

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

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

For a destructive tool with no output schema and no annotations, this description is thin. It gives the core purpose and a dry-run tip, but omits details about required arguments (other than the schema), what happens on execution, failure modes, or how to interpret the result. An agent would still face uncertainty about side effects and correct usage beyond the basic 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?

Schema description coverage is 0% and the description does not explain the parameters (model_id, table_ref, column_ref, dry_run) beyond their names. While the names are somewhat self-explanatory, the description adds no additional meaning, constraints, or format details. It fails to compensate for the complete lack of schema descriptions, leaving the agent to infer parameter semantics from names alone.

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

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

The description states 'Delete a column from a table' – a specific verb, resource, and object. It clearly distinguishes from siblings like create_column, rename_column, update_column, and delete_table. The purpose is unambiguous and immediately actionable.

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 advises 'Destructive: prefer dry_run first,' which gives a clear safety guideline for invocation. It suggests using dry_run as a precaution, but it does not explicitly name alternatives or state when not to use this tool. This is useful guidance but lacks comparative routing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly labels the operation as 'Destructive' and advises dry_run, which is valuable. However, it does not disclose the irreversible nature in detail, what happens to dependent objects, or the exact effect of dry_run. This is adequate but not comprehensive.

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

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

The description is extremely concise with two short sentences. It front-loads the purpose ('Delete an index') and immediately follows with a critical safety note ('Destructive: prefer dry_run first'). There is no redundant wording, and every sentence earns its place.

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

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

For a destructive operation with no annotations and no output schema, this description is thin. It does not mention success/failure responses, side effects on related objects, prerequisites (e.g., model must be open), or recovery options. The dry_run tip is a start, but it leaves many gaps for an agent to safely and correctly invoke the 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%, and the description adds no explanation for any of the four parameters. While the parameter names (model_id, table_ref, index_ref, dry_run) are somewhat self-explanatory, the description fails to clarify their roles, formats, or relationships. The tool relies entirely on the schema, which is insufficient given the lack of description-level semantics.

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

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

The description clearly states the verb 'delete' and the resource 'index', which distinguishes it from sibling tools like delete_column, delete_table, and delete_reference. The addition of 'Destructive: prefer dry_run first' further clarifies the operation's nature. There is no ambiguity about what this tool does.

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 a clear usage directive to prefer dry_run first, which is helpful for safe execution. However, it does not specify when to use this tool versus alternatives (e.g., update_index or rollback_model) or any prerequisites like needing an open model. The guidance is limited to a safety tip rather than full usage 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 explicitly labels the operation 'Destructive' and discloses that FK columns are kept, which is valuable behavioral context. It could add more about permissions or reversibility, but the warning 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 two short sentences with no filler, front-loading the core action and then the warning. It is efficient and well-structured, though it could be slightly more organized.

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

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

For a destructive delete operation, the description covers the key behavioral aspects (destructive, dry_run preference, column retention) but omits parameter details and return behavior. Without an output schema or annotations, more detail would be helpful, though it is not critically incomplete.

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 by explaining parameters. It does not mention model_id, reference_ref, or dry_run at all, leaving the agent to guess their semantics from the schema titles alone. This is a significant gap.

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

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

States the specific action 'Delete a foreign-key reference' and clarifies a key side effect (FK columns are kept). This clearly distinguishes it from delete_column or delete_table, and the resource type is unambiguous.

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

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

Gives the explicit advice to prefer dry_run first, which is a practical usage instruction. However, it does not mention alternatives or when not to use this tool, leaving the agent to infer context from the tool name.

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

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

With no annotations, the description carries the full burden and discloses the key behavioral trait: the operation is destructive and cascades to columns, keys, indexes, and attached references. It also recommends a dry_run, giving the agent a safe workflow. It does not mention irreversibility or permission requirements, but the most critical side effects are 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?

Two short sentences that front-load the purpose and then add the safety note. Every phrase adds information; there is no 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?

The destructive/cascade behavior is well conveyedcommand, and the dry_run recommendation provides useful context. However, with 0% schema coverage and no output schema, the description still leaves required parameter semantics and result behavior to inference, making it adequate but incomplete.

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

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

Schema description coverage is 0%, so the description needed to explain model_id, table_ref, and dry_run; it only partially addresses dry_run by recommending it. The identity and format of table_ref are left completely unspecified, so an agent may not know what value to supply.

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?

Clearly states the action and resource ('Delete a table') and adds the cascading scope (columns, keys, indexes, and attached references), which distinguishes it from sibling delete tools like delete_column and delete_reference. The resource and effect are unambiguous.

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

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

The phrase 'prefer dry_run first' gives explicit safety guidance for using this destructive tool, and the cascading note implies this is the correct tool when removing an entire table rather than a single column, key, or reference. It does not name sibling alternatives or when-not-to-use cases, so it is not 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, the description carries the full burden. It discloses that the tool can create a new model or extend an existing one, and that dry-run is supported. However, it does not describe side effects on persisted models, reversibility, or failure behavior beyond that.

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 central purpose, then falls to essential execution context and dry-run note. Every sentence adds value; the inline spec shape is dense but necessary.

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 a complex nested input, no annotations, and no output schema, the description provides only high-level top-level structure. It does not detail the expected shape of tables/entities, relationships, indexes, or domains, nor what the tool returns or how atomicity affects execution. It is adequate but has clear gaps.

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

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

Schema description coverage is 0% and the spec schema is an open object, so the description compensates by listing the top-level structure: model, tables/entities, relationships, domains, indexes, and the supported 'PDM' | 'CDM' | 'LDM' enum. It also defines dry_run and model_id, but does not explain the atomic 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 states a specific verb ('Materialise') and a clear resource ('a full design spec into a NEW model (or extend an existing one via model_id)'). It also includes an explicit spec structure, making it easy to distinguish from piecemeal sibling tools like create_table or create_model.

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 'The AI supplies the design; this tool executes it' implies when to use the tool, but no explicit alternatives, exclusions, or when-not-to-use guidance is provided. It does not contrast with sibling tools such as validate_model or apply_schema_patch.

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

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

With no annotations, the description carries the full burden and does well: it discloses the file creation side effect, the directory prerequisite, the DBMS restriction/error behavior, and the return value. It stops short of explaining overwrite behavior or what exactly 'file info' contains, but it is still 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?

Three concise sentences with no filler. The main purpose is front-loaded, followed by output_path semantics, return value, and the DBMS constraint. Every sentence adds 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 no annotations and no output schema, the description covers the essential inputs, output, file behavior, and failure mode well enough for an agent to invoke it. Minor gaps remain around overwrite semantics and the contents of the returned file info, but nothing blocks correct 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?

Schema description coverage is 0%, so the description must compensate for the schema's silence. It explains output_path and clarifies how the dbms parameter behaves, but model_id is left implicit and no value formats or defaults for dbms are described. Partial compensation.

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: 'Generate SQL DDL for a PDM'. It also names the method ('PowerDesigner's native database generation') and the output target, making the tool's function easy to distinguish from schema-inspection and table-editing 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 gives a clear constraint: the model's own DBMS is used and requesting a different dbms returns an error. However, it never explicitly says when to choose this tool over alternatives like create_database_schema or apply_schema_patch, so usage guidance is implied rather than fully stated.

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

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

No annotations are provided, so the description must carry the behavioral burden. It says 'full detail' but doesn't specify what that includes, whether permissions are needed, or what errors might occur. It adds minimal behavioral context beyond the name.

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

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

The description is a single, concise sentence with no wasted words. However, it is too terse to be genuinely helpful – it sacrifices necessary detail for brevity, so it's not a 4 or 5.

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 getter tool with no output schema and no annotations, the description is under-specified. It doesn't mention what 'full detail' includes, the role of each parameter, or the return format. An agent would need to inspect other tools or guess to call it correctly.

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

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

Schema description coverage is 0% and the description doesn't explain any of the three parameters (model_id, table_ref, column_ref). The agent must infer their meaning from names alone, which is inadequate for a tool with no other 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 'Get one column's full detail' clearly states a specific verb (get) and resource (column), and the qualifier 'one' implies singular lookup, distinguishing it from list_columns or search_columns. However, it does not explicitly name alternatives, so it's not 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?

No guidance on when to use this tool versus list_columns, search_columns, or get_table. The description offers no context about prerequisites (like model_id and table_ref) or scenarios where this tool is preferred.

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, and the description gives no behavioral context beyond the verb 'Get'. It does not disclose return format, potential side effects (though unlikely), authorization requirements, or any operational details. The description is essentially a restatement of the tool name.

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

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

The description is extremely short (one sentence), which is concise, but it is under-specified rather than efficiently informative. There is no structure or front-loading of key facts; it merely restates the tool's purpose with no added detail.

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 two required parameters and no output schema, the description is inadequate. It does not explain what a 'domain' is, what the response contains, or how this differs from list_domains. An agent cannot confidently call this tool based on the description alone.

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

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

Schema description coverage is 0%, and the description does not explain the meaning or usage of 'model_id' or 'domain_ref'. It adds no value beyond the parameter names, which are not self-explanatory in context. The agent receives no assistance in constructing valid 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 states a clear verb ('Get') and resource ('domain'), and specifies it returns 'detail' for one domain. It is not a tautology, but it does not differentiate from the sibling 'list_domains' which likely retrieves all domains; the singular focus is implied by 'one' but not explicitly contrasted.

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 like list_domains or other get_* tools. There is no mention of prerequisites, context, or exclusions. The intended usage is only implied by the name and parameters.

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

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

With no annotations, the description must carry the full behavioral disclosure burden. It implies a read operation by saying 'Get', but it does not explicitly state that the tool is read-only, what 'full detail' includes, whether it may fail for missing references, or what the return shape will be.

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

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

The description is a single concise, front-loaded sentence with no filler words. It is not overly verbose, though its brevity comes at the cost of omitted context.

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

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

The tool has three required parameters and no output schema, so the description should provide more context about how the parameters fit together. 'Full detail' is vague, and an agent is left without enough information about what qualifies as full detail or what the response will look like.

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 by explaining the three required parameters. It only mentions 'index' and does not explain how model_id, table_ref, and index_ref relate to each other or how to construct them for a valid call.

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

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

The description clearly identifies the action ('Get'), the resource ('index'), and the scope ('one index's full detail'), which distinguishes it from sibling tools like list_indexes and from create/update/delete operations. Even though it is terse, it leaves no doubt about what the tool does.

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 no guidance on when to use this tool versus alternatives such as list_indexes, get_table, or get_key. It does not state that this is the tool to use when you need the complete detail of a single index, nor does it mention any prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get one key by ref'. It does not state whether this operation is read-only, what is returned, or how errors behave. The phrase 'from list_keys' is the only added behavioral context.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the key source hint 'from list_keys' is included without bloat. This is appropriately sized for the tool's simplicity.

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 three required parameters, no output schema, and no annotations, this description covers only the source of key_ref and leaves the role of model_id and table_ref implied. It does not describe the return value, prerequisites, or relationship to sibling tools, so an agent would need external inference to invoke this confidently.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It adds meaning only for key_ref via 'by ref (from list_keys)'; model_id and table_ref receive no explanatory meaning beyond their names. This is insufficient for an agent to confidently know the exact scope 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 states a specific verb ('Get') and resource ('one key'), with the precise selection mechanism 'by ref'. The parenthetical '(from list_keys)' adds useful context about where the ref comes from, though it does not fully contrast against sibling get_* siblings beyond that.

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 'from list_keys' implies the intended workflow: first call list_keys, then use get_key with a key_ref from that result. However, there is no explicit guidance on when to choose this tool over alternatives like get_index or get_reference, leaving usage mostly inferred.

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

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

With no annotations, the description carries the full burden. 'Get' conveys a read-only operation, and 'open model' implies a prerequisite, but the description does not disclose error behavior, whether the model must already be open, or how counts are computed. It is adequate but not rich.

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

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

One concise, front-loaded sentence states the core purpose and then lists the exact data returned. There is no filler, repetition of the tool name, or unnecessary context.

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

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

For a single-parameter read tool with no output schema, this description is largely complete: it identifies the required input and enumerates the return contents. It omits minor details like error cases or prerequisites, but those are not critical for a straightforward getter.

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 adds meaning by clarifying that model_id refers to an open model and that the result contains detailed metadata for that one model. It does not provide format, examples, or validation details, but for a single string parameter it is minimally sufficient.

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

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

The description names a specific verb ('Get'), a specific resource ('one open model'), and enumerates the returned fields (kind, name, code, file, DBMS, counts). This clearly distinguishes it from sibling list tools like list_open_models, which would return summaries of multiple models.

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

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

No guidance is given about when to choose this tool over alternatives such as list_open_models, model_snapshot, or inspect_schema. 'One open model' implies it targets a single model by ID, but there is no explicit when-to-use or when-not-to-use 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 only states 'Get details', which implies a read operation but does not explicitly confirm it is non-destructive, nor does it mention any prerequisites (e.g., model must be open), error handling for missing packages, or the structure of the returned data. The lack of disclosure is a significant gap given zero annotation coverage.

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

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

The description is a single, direct sentence with no superfluous words. It is front-loaded with the action and resource. However, it is so brief that it sacrifices important contextual information, though conciseness itself is well-handled.

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

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

The tool has two required parameters and no output schema or annotations. The description does not specify what 'details' are returned, how model_id and package_ref interact, or provide examples. An agent would lack crucial information about expected inputs and outputs, making the description incomplete for reliable 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?

The schema provides parameter names but no descriptions, and schema coverage is 0%. The description adds some meaning by clarifying that package_ref can be a ref, code, or name, but it does not explain model_id at all. With both parameters required, the description should compensate for the schema's silence but only partially addresses one 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 clearly states it retrieves details of a single package using package_ref, and mentions it can be identified by ref, code, or name. This distinguishes it from list_packages, which lists all packages. However, it does not elaborate on what 'details' includes or how it differs from other get_* tools, so it stops short of a perfect score.

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 explicit guidance is given on when to use this tool versus alternatives. The phrase 'Get details of one package' implies using it when a specific package's details are needed, but it does not mention when not to use it, nor does it reference list_packages or other sibling tools for alternative scenarios.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but does not explicitly state read-only intent, potential side effects, required permissions, or error behavior. The phrase 'full detail' is vague and does not clarify the return format or any limitations.

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

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

The description is a single sentence with no wasted words, and the core purpose is front-loaded. It is appropriately concise for a simple retrieval operation, and there is no unnecessary content or fluff.

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 two undocumented parameters, no output schema, and no annotations, this description is incomplete. The agent cannot determine the expected input format, return structure, or any prerequisites (e.g., whether the model must be open). It fails to provide sufficient context for reliable tool 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?

The input schema has 0% two parameters with no description coverage, and the description does not explain 'model_id' or 'reference_ref'. The agent is left to guess their meanings from the parameter names alone, which is insufficient for reliable invocation. The description adds no semantic value beyond what the schema titles already provide.

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 ('Get') and the resource ('one reference'), and adds 'full detail' to indicate the scope. It is not a tautology and distinguishes the tool as retrieving a single reference rather than a list. However, it does not mention any differentiation from sibling tools like list_references or other get_* tools, relying on the name to imply uniqueness.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_references or search. There is no mention of context, prerequisites, or conditions that would make this tool the appropriate choice. The agent must infer usage entirely from the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation and does not describe what happens for invalid refs, whether the model must be open, or what the response contains. 'Get' implies a read, but no safety or error behavior is disclosed.

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

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

The description is one succinct sentence with no filler, front-loads the core operation, and avoids repeating schema information. It is appropriately concise for a simple getter.

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 getter, the description is mostly sufficient to guide invocation, but it lacks explicit usage guidance, returns expectations, and behavioral guarantees. With no output schema or annotations, a bit more context 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%, so the description must compensate by explaining the parameters. The phrase 'by ref' clarifies relationship_ref, but model_id is left entirely to its name, and no formats, formats, or context are provided for either 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 states a specific verb ('Get'), a specific resource ('one CDM/LDM relationship'), and a selection method ('by ref'). It clearly distinguishes this from list_relationships and other relationship tools because it targets a single relationship by identifier.

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

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

The description implies when to use the tool: when you already have a relationship_ref and want one specific relationship. However, it does not explicitly name alternatives like list_relationships or explain when not to use this tool, leaving routing partly to inference.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains that this is a connectivity/capability check, mentions the mock backend possibility, and lists the returned data: version, attach mode, and open model count.

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

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

Three concise sentences with no filler: what the tool does, when to call it, and what it returns. The most important usage guidance 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 zero-parameter connection check with no output schema, the description is complete. It specifies the return fields, making the agent aware of what to expect without needing to inspect output schema.

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

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

The tool has zero parameters and an empty input schema, so parameter semantics are inherently non-applicable. The baseline of 4 is appropriate because no parameter disambiguation is needed.

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

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

States a specific verb and resource: checking the PowerDesigner connection and reporting server capabilities. This clearly distinguishes it from model- and schema-focused siblings by focusing on server-level reachability and state.

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

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

Explicitly tells the agent to call this first to verify that PowerDesigner or the mock backend is reachable. It gives clear context and sequencing, though it does not explicitly state when not to use it or name 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 behavioral disclosure burden. It usefully enumerates the returned components and notes the lookup can be by ref or code, which clarifies the operation. It does not mention prerequisites like an open model, error behaviors, or response shape, but for a read-only detail lookup the disclosed scope is reasonably 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?

One compact sentence front-loads the purpose and then lists the exact detail categories. Every word contributes value; 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?

The description gives a good overview of what will be returned, but with no output schema and zero schema documentation for the two parameters, an agent still lacks format details for model_id and table_ref. This is adequate for a simple lookup but leaves key invocation details unstated.

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 clarify parameters. It adds that table_ref can be a ref or code, but it does not explain what model_id refers to or the accepted formats for either parameter. This is insufficient for confident invocation.

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

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

States a specific resource ('one table/entity') and a concrete action ('get full detail'), and itemizes the returned content: columns, keys, primary key, indexes, and references. This clearly distinguishes it from broader siblings like list_tables/search_tables and narrower ones like get_column.

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 when-to-use or alternative-selection guidance is provided. There is no mention of when to prefer this over list_tables or search_tables, nor when get_column or get_key would be more appropriate.

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

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

With no annotations, the description must reveal behavioral traits. It does help by saying this is an 'inspect' (implying a read-only operation), and it notes pagination and the content ('tables + foreign keys view'). However, it does not explicitly state that it never modifies the schema, nor does it explain response size or how pagination is returned. A brief 'read-only' declaration would strengthen it, but it is at least passable for a non-destructive inspection 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 three sentences, front-loads the core purpose first, and each additional clause provides necessary usage or behavior. There is no fluff, and it remains compact while covering purpose, mode, table filter, pagination, and the strategic advantage over list_* calls.

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 having 5 parameters, no output schema, and no annotations, the description gives a solid high-level of the tool's behavior and when to use it, saving the agent from parsing many list_* alternatives. It does not detail parameter semantics (especially model_id) or paginated response shape, which would make it fully complete, but for a read-only schema inspection tool the essential context is provided.

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

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

The schema has 0% description coverage, so the textual description must compensate. It defines mode ('summary'|'detail'), mentions the optional single table, and indicates that the tool is paginated, which maps to the page/page_size parameters. It omits the significance of model_id entirely (a required parameter) and leaves summary/detail semantics to inference. Partial compensation, but not complete.

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

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

The description clearly states it inspects the whole schema at once, specifies the resource (schema) and type of output (tables + foreign keys view), and contrasts itself with the many list_* siblings. This leaves no ambiguity about what the tool does and how it differs from the alternative calls.

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

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

It explicitly says 'use this instead of many list_* calls to save context', which names the alternative tools and gives a clear reason to use this tool. It also signals that a single table can be selected via the 'optional single table', but it does not spell out when NOT to use it (e.g., for fetching a single column or a specific relationship).

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 must disclose behavioral traits. It states the operation is a read ('List') but does not explicitly confirm read-only safety, mention any side effects, permissions, rate limits, pagination, or return format. The agent is left guessing about response structure and any constraints, which is a significant gap for a tool with no structured annotations.

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

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

The description is a single sentence with no wasted words. It front-loads the core action and immediately notes the optional search capability. It is concise, though the brevity sacrifices necessary detail; still, for what it conveys, it is well-structured.

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

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

For a list operation with three parameters and no output schema, the description is underspecified. It lacks return format, pagination behavior, sorting, any constraints on the search query, and does not clarify the roles of the two required parameters. Sibling tools like search_columns and get_column exist, but the description offers no context to distinguish use cases, leaving the agent with insufficient information to use it correctly.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It only addresses the optional 'query' via 'Optional text search', leaving 'model_id' and 'table_ref' entirely unexplained. Without knowing what these identifiers refer to (e.g., model UUID, table reference format), the agent cannot correctly invoke the tool.

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

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

The description clearly states the action ('List columns of a table') and mentions 'full attributes' and 'optional text search', which distinguishes it from single-column retrieval (get_column) and broader searches (search_columns). However, it does not explicitly name sibling alternatives or specify the scope beyond the table, so it lacks the sharpest 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?

There is no guidance on when to use this tool versus alternatives like get_column or search_columns. No mention of prerequisites (e.g., model must be open), no exclusion cases, and no indication of when text search is appropriate. The description implies a straightforward listing but does not help the agent decide between this and sibling tools.

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

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

With no annotations, the description carries the burden of disclosing behavior. The verb 'List' reasonably implies a read-only query operation, and the description clarifies what domains are, but it does not mention return format, pagination, error conditions, or whether only user-defined or all domains are returned. This is minimally adequate but leaves gaps.

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

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

A single sentence that is front-loaded with the action and resource, with no filler or repetition. The parenthetical definition earns its place by clarifying the potentially ambiguous term 'domains'.

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 list tool, the description conveys the core operation and scope, but lacks guidance on prerequisites, return shape, and alternatives. Since there is no output schema and no annotations, a bit more context would be needed for the tool to be fully self-sufficient.

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 documenting model_id, but it only says 'of a model', which loosely ties the parameter to the model being queried. It does not explain the expected format of model_id, how to obtain it, or any constraints beyond the schema's bare type string.

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

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

The description clearly identifies the action ('List') and resource ('domains'), and adds a parenthetical definition ('reusable data type definitions') that removes ambiguity about what domains are. It also scopes the operation 'of a model' and is distinct from siblings like list_tables or get_domain.

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

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

No guidance is given about when to use this tool vs alternatives such as get_domain, or whether the model must be open/loaded first. The usage context is only implied by the verb 'List' and the resource name, with no explicit when-to-use or when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden. It discloses what the tool shows (unique flag, covered columns) and the index types supported, but it does not explicitly state that it is a read-only operation or mention any permissions or side effects. The verb 'list' implies non-destructive behavior, but for a tool with zero annotation coverage, a bit more explicitness would be stronger.

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

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

The description is a single sentence that front-loads the core purpose and scope, then adds detail on output contents and supported index types. No wasted words; every clause adds 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?

For a simple listing operation with two parameters and no output schema, the description covers the essential facts: what it does, scope, and what it returns. It does not describe the exact return format (e.g., list of objects), but for a list tool that is typically self-evident. The absence of annotations is mitigated by the clear scope and behavior.

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 clarify parameters. It explains table_ref's role (specifying a table vs. whole model) and its default behavior via the 'one table or whole model' phrasing. model_id is not explicitly defined, but its name and required status make it self-evident. This compensates well 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 lists indexes with a specific scope (one table or the whole model) and specifies what it shows (unique flag, covered columns, index types). This distinguishes it from siblings like get_index (single index) and list_keys (keys), giving an agent a precise understanding of the 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: if you want indexes for a specific table, provide table_ref; otherwise, leave it empty for the whole model. It does not explicitly name alternatives or state when not to use this tool, but the scope condition is clear enough for an agent to decide between this and get_index.

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 reveals that primary keys are flagged with primary=true and that composite keys are supported, which is useful. However, it does not specify whether foreign keys or other key types are included, nor does it mention ordering, pagination, or any side effects, leaving the return scope ambiguous.

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, with two sentences and no filler. The primary purpose is front-loaded, and the additional sentence about primary key behavior is relevant. However, it could be slightly more explicit about what 'keys' encompasses, but the structure is efficient.

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

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

For a simple listing tool, the description provides a reasonable starting point but lacks crucial details about the exact set of keys returned (primary only vs. all constraints) and the output format. With no output schema and low parameter coverage, the description is incomplete for an agent to fully understand the tool's behavior without prior context.

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 parameter documentation, but it does not mention model_id or table_ref at all. The parameter names are somewhat self-explanatory, but the description provides no additional meaning, leaving the agent to rely on assumptions about the 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 states a clear verb ('List') and resource ('keys of a table'), and adds detail about primary key representation. It does not explicitly differentiate from sibling 'get_key', but the plural 'keys' vs singular 'get' implies a list vs. single-item operation, so purpose is clear but not fully distinguished.

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 for enumerating keys but provides no explicit guidance on when to prefer this over alternatives like 'get_key' or 'list_columns'. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer the intended use case.

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 must carry the behavioral burden. It clearly indicates a non-mutating listing operation and provides context about the backup directory. It does not disclose additional traits like ordering, filtering, or whether only the latest backup is shown, but the operation is inherently low-risk.

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

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

The description is a single, well-structured sentence that starts with the action and includes relevant context without any 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?

For a zero-parameter listing tool, the description adequately covers what the tool does and where it operates. There is no output schema, so some return-shape detail could be added, but the definition is sufficient for an agent to invoke the tool correctly.

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

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

The tool has zero parameters, and the empty schema is fully described. The baseline for no parameters is 4, and no additional parameter explanation is needed.

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

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

The description uses a clear verb ('List') and a specific resource ('model backup files'), and further explains where they live and how they are created. This clearly differentiates it from sibling tools like list_open_models or rollback_model.

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

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

The description implies when to use the tool: when you need to see backup files produced by transactions and save operations. However, it does not explicitly mention alternatives or state when not to use it, such as in favor of rollback_model or model_snapshot.

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 carries the burden of disclosure. It clearly scopes the operation to currently open models and lists the output fields, giving a solid picture of behavior. It does not explicitly state that the operation is non-destructive or what happens with an empty session, but 'List' strongly implies a read-only 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?

A single, front-loaded sentence that states the action, scope, and return fields without any filler. Every word contributes useful information.

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

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

With no parameters and no output schema, the description adequately explains what the tool returns. It is complete enough for an agent to call it correctly, though it could mention the possibility of an empty list or whether results are ordered.

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 parametersable, so the schema already provides complete coverage. No parameter explanation is needed in the description.

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

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

The description uses a specific verb ('List') and resource ('all models currently open in PowerDesigner') and enumerates exactly what is returned: kind, name, code, file path, DBMS, and object counts. This clearly distinguishes it from related tools like get_model_info or list_model_backups.

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

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

The description implies when to use the tool: whenever you need to see all currently open models. However, it does not explicitly mention alternatives or state when not to use it, such as when a specific model's details are needed instead.

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 behavior disclosure. The verb 'List' signals a non-mutating read operation, and the parenthetical adds semantic context, but no details such as return format, whether the model must be open, or recursion/ordering behavior are given.

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

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

The description is a single, compact sentence that front-loads the action and resource, with a useful clarifying parenthetical. There is no filler, repetition, or unnecessary detail.

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 one-parameter listing tool, the description is nearly complete: it identifies the operation, the resource, and the scope. Missing behavioral details like expected output or prerequisites are minor at this complexity level.

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

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

Schema description coverage is 0%, so the description must compensate, but it only ties model_id to the model scope via 'of a model.' The parameter name is self-explanatory enough for basic use, yet no format, requirements, or constraints are added beyond what the schema's type/title already convey.

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

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

The description uses a specific verb ('List') and resource ('packages'), and the parenthetical clarifies that packages are sub-models/namespaces, making the operation clear. It does not explicitly differentiate from the sibling get_package, but the list-vs-get distinction is reasonably inferable.

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 'of a model' implies this tool is used when the agent needs the package list for a specific model, but there is no explicit when-to-use versus alternatives or exclusions. Usage context is only implied, not stated.

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

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

With no annotations provided, the description carries the full burden. It transparently discloses the output content (parent/child tables, join pairs, cardinality, mandatory flag), which is the key behavioral information for a listing operation. It does not mention any side effects or error conditions, but as a read-only list, the output disclosure is sufficient and adds value beyond the bare 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?

A single, tightly worded sentence that leads with the verb and resource, followed by the specific output fields. There is no redundancy or filler, and every clause contributes meaning.

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?

Since there is no output schema, the description adequately explains what the tool returns. It covers the essential fields an agent needs to know. It omits potential details like pagination, error behavior, or model-open prerequisites, but for a straightforward list operation on a known model, these are not critical and the description 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 description coverage is 0%, so the description must compensate for the single parameter model_id. The phrase 'of a model' indicates that model_id identifies the target model, but it does not add format or constraint details. Given the parameter is obvious and the description gives minimal context, a baseline score of 3 is appropriate.

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 starts with a specific verb (List) and resource (foreign-key references of a model), and enumerates the returned fields (parent/child tables, join column pairs, cardinality, mandatory flag). This clearly differentiates it from siblings like get_reference (singular) and list_relationships (logical relationships), and from other list tools like list_tables or list_keys.

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 when a model's foreign-key references are needed, and clarifies the scope to PDM references. However, it does not explicitly mention alternatives or exclusion criteria, such as 'use list_relationships for logical relationships' or 'only valid for physical data models'. This leaves the agent to infer context from the sibling names.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool lists entity-to-entity relations and is scoped to CDM/LDM models, which hints at a read-only operation. However, it does not explicitly state it is read-only, nor describe return content, pagination, error cases, or any requirements such as model access. Thus it offers basic scoping but leaves many behavioral traits unstated.

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

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

Two sentences, no filler. The core purpose is front-loaded and the alternative routing is included second, leaving zero wasted content and making it quick to scan.

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

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

The tool has only one required parameter and no output schema. The description captures the most likely confusion point—LD vs PDM—by giving a sibling pointer. Yet it still leaves the response format unspecified, does not note whether the model must be open, and lacks any mention of how the returned relationships are structured, making it only partially complete for a no-annotation, no-output-schema 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 for the undocumented model_id. It only implies model_id refers to a CDM/LDM model, but gives no identifier format, whether the model must be open/loaded, or how to resolve it. That is minimal enrichment over an empty property field, failing the compensation burden.

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 explicitly states a specific action: 'List relationships of a CDM/LDM model (entity-to-entity relations)', which identifies the resource and verb clearly. It also differentiates itself from the sibling tool list_references with a direct pointer for PDM models, so an agent can distinguish them without inspecting schemas.

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 direct when-to-use guidance: this is for CDM/LDM models, and explicitly says 'For PDM models use list_references instead.' This is a clear alternative with a condition, leaving no ambiguity about which tool applies.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a listing operation, scoped to a model, with optional text search and package filtering, and that rows are intentionally brief. This is meaningful behavioral context, though pagination semantics and the need for an open model are left implied.

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

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

Two focused sentences with no filler. The core action and scope are front-loaded, followed by search/filter capabilities, then a routing hint. Every clause earns its place without repeating schema fields.

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?

Adequate for a basic paginated list: required model_id, optional filters, and the get_table fallback are all present. With no output schema and no annotations, however, the description omits pagination details and any indication of which row fields are returned, so an agent still has to infer some invocation expectations.

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 adds real meaning to query ('text search over code/name') and package_ref ('package filter'), and model_id is implied by 'of a model.' It does not explain page/page_size behavior or how pagination interacts with the returned brief rows, leaving those to be inferred from names and defaults.

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

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

The description is specific and action-oriented: 'List tables (PDM) or entities (CDM/LDM) of a model' and it clearly separates itself from get_table via 'Returns brief rows - use get_table for full detail.' However, it does not differentiate from the sibling search_tables, which overlaps with the built-in 'text search over code/name' behavior, so sibling distinction is incomplete.

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 a concrete routing rule: if you need full detail, use get_table instead. It also tells the agent that text search and package filtering are optional capabilities of this listing tool. It stops short of explaining when search_tables would be more appropriate, so it is useful but not exhaustive.

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 exist, so the description must disclose behavior. It explains the content of summary and detail modes but does not state whether the operation is read-only, potential side effects, or error conditions. The reference to restricting table codes is not backed by a schema parameter, adding 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 concise and front-loaded, stating the core action ('Convert the model into compact JSON') first, then elaborating on modes. 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?

For a tool with only two parameters and no output schema, the description covers the purpose and mode semantics adequately. However, the unresolved table-codes restriction and lack of behavioral notes (e.g., read-only guarantees) leave gaps that an agent may need to resolve.

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 enriches the mode parameter by explaining summary vs detail, but model_id is only self-evident from its name. More critically, it mentions an 'optionally restrict to given table codes' capability that has no corresponding parameter in the input schema, creating confusion about how to invoke that behavior.

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 converts the model into compact JSON, and specifies two modes (summary and detail) along with an optional restriction to table codes. This is a specific verb-resource pair, distinct from other model inspection tools like get_model_info or inspect_schema.

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

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

The description implies usage for obtaining a snapshot for reasoning but does not explicitly state when to use this tool versus alternatives such as inspect_schema or get_model_info. No exclusion criteria or conditional guidance is given.

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

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

With no annotations, the description carries the full behavioral burden. It does add one meaningful behavior detail: 'Set read_only=true to prevent modifications.' But it does not disclose what happens by default, what side effects opening a model may have, whether it registers the model as open, or what fields the returned 'info' includes.

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

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

Two sentences with no filler. The core action and file formats come first, and the read_only guidance is front-loaded as an imperative. Every clause earns its place.

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

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

For a two-parameter tool with no output schema, the description covers selection, file scope, and the read-only mode. It is slightly vague about what 'its info' contains, but an agent can likely invoke the tool correctly with just the path and the read_only guidance provided.

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

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

The schema has 0% description coverage, so the prose must add meaning. The description clarifies that path points to a PowerDesigner model file with supported extensions, and it explicitly explains the read_only parameter's effect. This is meaningful compensation for the schema's lack of 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 description names a specific action ('Open'), a specific resource ('PowerDesigner model file'), and the supported formats (.pdm/.cdm/.ldm), and states the outcome ('return its info'. This distinguishes it clearly from sibling tools like close_model, create_model, or get_model_info.

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

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

The intended use is implied: open a model file when you want its info, optionally read-only. However, it never explicitly explains when to choose open_model over alternatives like get_model_info, list_open_models, or create_model, nor does it mention exclusions or prerequisites.

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

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

With no annotations, the description must carry behavioral disclosure; it labels the operation 'Destructive' and recommends dry_run, which is meaningful. However, it doesn't disclose what happens to dependent objects, whether the change is reversible, or what response/errors to expect, so some burden remains unmet.

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

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

Two short sentences with no filler; the destructive warning is front-loaded and the dry_run guidance is actionable. Every word earns its place.

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

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

For a destructive three-parameter schema mutation with no annotations and no output schema, the description is serviceable but thin: it warns and suggests dry_run, but doesn't describe the effect on the model or the expected result. It is adequate for a straightforward operation, yet missing details an agent may need for safe use.

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

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

Schema description coverage is 0%, so the description should compensate. It only gestures at dry_run ('prefer dry_run first') and does not explain model_id or table_ref, leaving their formats and required semantics to inference. The self-explanatory names and schema titles carry most of the weight.

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?

Description states exactly what the tool does with a specific verb ('Remove') and resource ('primary key from a table'). It is clearly distinct from siblings like create_primary_key and set_primary_key.

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 explicit execution guidance: 'Destructive: prefer dry_run first.' This tells the agent to use the dry_run flag before committing. It doesn't explicitly enumerate when-not-to-use or alternatives, but no genuine alternative exists for removing a primary key.

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 mentions dry_run support, indicating a non-committing mode, but does not describe mutation effects, error behavior, impact on related objects (e.g., references), or reversibility. The behavioral transparency is minimal 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 a single, compact sentence that leads with the core action and includes the dry_run capability. There is no filler or redundant information; every word earns its place.

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

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

Given six parameters (three required) and no annotations or output schema, the description is too sparse. It lacks information about success/failure responses, what dry_run returns, preconditions, or side effects. An agent would struggle to call this tool correctly without external knowledge.

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 adds meaning by clarifying that 'Name and/or Code' map to new_name and new_code, and that dry_run is available. However, it does not explain the required parameters (model_id, table_ref, column_ref) beyond what their names imply, leaving some semantic gaps.

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 'Rename' and the resource 'a column', and specifies what can be renamed ('Name and/or Code'). It distinguishes itself from sibling tools like rename_table (different resource) and update_column (broader update operation). The purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as update_column or rename_table. No exclusions or conditions are provided, leaving the agent to infer usage based on the name alone. The mention of dry_run hints at a testing use case but doesn't clarify when to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions dry_run support, which is useful, but it does not describe the mutation behavior, side effects on references, reversibility, or what the response contains. For a mutation tool, this is a significant gap.

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

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

The description is extremely concise, front-loading the core action. However, it is under-specified; it omits crucial parameter details and behavioral information. The brevity is not a virtue here because it leaves the agent with too little guidance.

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 mutation nature, lack of annotations, no output schema, and 5 parameters with 0% schema coverage, the description is far from complete. It does not explain return values, side effects, or parameter semantics, leaving critical gaps 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?

The schema has 0% description coverage, and the tool description only minimally maps new_name and new_code to 'Name and/or Code'. It does not explain model_id, table_ref, or the semantics of dry_run or the default empty strings. This leaves the agent to infer parameter behavior, which is inadequate for a 5-parameter tool.

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

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

The description clearly states the action (rename), the resource (table), and the specific fields (Name and/or Code). This distinguishes it from sibling tools like rename_column, which targets columns. It's specific and unambiguous.

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

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

The description implies usage for renaming a table, but provides no explicit guidance on when to use this tool versus alternatives like update_table or rename_column. It does not mention exclusions or prerequisites. The dry_run note is a minor usage hint, but overall the tool lacks clear contextual routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses a concrete side-effect sequence: closes the model, restores the file, and reopens it. It does not warn about potential data loss or failure cases, but it meaningfully reveals the operation's 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?

Two sentences with no filler. The main purpose is front-loaded, and the behavioral sequence is stated compactly in the second sentence.

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

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

For a simple two-parameter tool with no output schema and no annotations, the description covers the operation sequence and connects backup_file to list_model_backups. Explicit risk warnings and invalid-backup behavior would be useful additions, but the essential invocation context is present.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies backup_file's source (list_model_backups) and default behavior ('latest backup'), but model_id is only inferable from its name and title.

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

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

The description names a specific verb ('Restore'), a concrete resource ('a model'), and a source ('backup file'). It also distinguishes the tool from siblings like list_model_backups or open_model by describing the close/restore/reopen cycle.

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

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

It gives concrete usage guidance: omit backup_file to use the latest backup, or pass a value obtained from list_model_backups. It doesn't explicitly state when not to use this tool versus open_model/close_model, but the context is clear and the backup-file source is named.

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, and it is unusually transparent about side effects: the model_id may change, models are reopened, and deletions without backup cannot be undone. It also and explains the journal fallback and the explicit reporting behavior well beyond what the tool name alone conveys.

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 two-sentence description is tightly structured, front-loads the main action, and then supplies the required fallback behavior in the second sentence. There is no filler or repetition, and every sentence adds useful operational detail.

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

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

For a mutation tool with no annotations and no output schema, the description covers backup restoration, model reopening, the journal-based undo path, model_id changes, and the unrecoverable deletion case and explicit this exception. The only minor gap is that it does not describe the transaction lifecycle prerequisite, such as the need for a transaction started by begin_transaction.

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 never mentions txn_id specifically and schema description coverage is 0%, and txn_id carries only the title 'Txn Id.' For a single self-evident identifier parameter this is not a serious issue, but the description adds no added semantic guidance about where txn_id comes from.

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

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

The description starts with a specific verb and resource: 'Roll a transaction back,' then explains the restoration behavior for file-backed models. This clearly separates rollback_transaction from sibling tools like rollback_model, begin_transaction, and rollback_model by describing the operation at transaction scope, not just single-model rollback.

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 conditional usage context: file-backed models are restored from backup, and the undo path uses the operation journal otherwise, and deletions without backup cannot be undone. It does not explicitly name rollback_model as an alternative for single-model rollback, so it stops just short of a fully explicit when-to-use list.

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

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

With no annotations present, the description carries the behavioral burden, and it does disclose an important behavior beyond the schema: the operation targets the model's existing current file and fails with a clear error when no save has happened. It does not cover permissions or id-source details, but for a simple save action the key failure mode and fallback are disclosed.

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

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

Two compact sentences with no filler: the main action comes first, the failure condition follows, and the sibling pointer is folded into the same sentence. Every word earns its place.

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

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

For a tool with one parameter and no output schema, the description covers the main operational knowledge an agent needs: what gets saved, where it gets saved, what happens in the failure case, and which sibling to use instead. It could add a note about requiring an open model, but that gap is minor given the clarity.

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 only provides a bare model_id string, so the description adds meaning by tying model_id to a model that already has a current file and distinguishing the first-save case. It does not explicitly say model_id must come from an open model, but for a single simple parameter this adds genuine context 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?

States a specific action and resource — 'Save a model to its current file' — and immediately distinguishes itself from the save_model_as sibling by noting the never-saved case. An agent can tell this tool from save_model_as without opening the sibling's schema.

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

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

Gives an explicit when-not-to-use rule: if the model was never saved, use save_model_as first. This clearly routes the agent to the correct alternative instead of leaving the decision implicit.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses auto-extension appending and the no-overwrite constraint, but omits what model_id refers to (e.g., an already-open model), failure behavior when the file exists, and whether this copies or renames the original.

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

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

Two sentences with zero filler: core action first, behavioral constraint second. Every clause earns its place.

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

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

For a 2-required-param mutation tool with no annotations and no output schema, the description covers the essential save-as behavior and its key constraint. However, it leaves model_id semantics, failure behavior, and post-save state (is the model still open, and where?) unaddressed.

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

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

With 0% schema coverage, the description must compensate for the schema's silence. It clarifies path semantics (a file path with auto-appended extension) but leaves model_id undefined — the agent must infer it means a model currently open in the session.

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?

'Save a model to a new file path' names a specific verb, resource, and target. The extension detail adds precision, and the word 'new' differentiates from the sibling save_model, though it never names that sibling explicitly.

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 'target file must not exist yet' precondition implies when the tool can be invoked, but there is no explicit guidance on when to choose this over save_model, open_model, or other model-related siblings. Context is implied, not stated.

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

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

With no annotations, the description carries the full burden. It discloses the return shape (table_code + column detail rows) and the search semantics (substring match). It does not mention pagination behavior, case sensitivity, or that it is a read-only operation, though these are likely inferred. It adds some value but could be richer given no annotation support.

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

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

Two concise sentences with no fluff. The main action is front-loaded, and the return format is stated. Every word adds value, making it efficient for an agent to parse quickly.

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 5-parameter tool with no output schema and no annotations, the description is underspecified. It does not explain the meaning of 'model_id', pagination parameters, or behavior on empty results. An agent would likely need to infer these from the schema or probe the tool, which reduces completeness.

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

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

Schema coverage is 0%, so the description must compensate. It explains 'query' via 'substring in code/name' and 'table_ref' via 'whole model (or one table)', but it does not clarify 'model_id' (which model to search), 'page', or 'page_size' (pagination). These are left entirely to the schema, which has minimal titles. The description covers only a fraction of the 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 the action (search), the target resource (columns), the scope (whole model or one table), and the matching criteria (substring in code/name). It also specifies the return format (table_code + column detail rows), which distinguishes it from siblings like search_tables (which searches tables) and list_columns (which lists all columns without a search filter).

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

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

The description implies usage context: searching columns by substring across a model or a specific table. However, it does not explicitly state when to prefer this over list_columns or get_column, nor does it mention exclusions (e.g., 'if you need exact column details without search, use get_column'). The 'whole model or one table' phrasing gives some guidance but lacks explicit 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 provided, the description must disclose behavioral traits. It adds case-insensitivity and substring matching, but omits crucial details such as pagination behavior, return format, and whether the operation is read-only. This leaves significant behavioral 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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core operation and key constraint (case-insensitive substring) 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?

For a tool with 4 parameters, 2 required, and no output schema, the description is incomplete. It does not explain required parameters or pagination semantics, so an agent cannot reliably construct a correct invocation. The essential context 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 explain parameters. It implies 'query' is the substring but does not clarify the roles of 'model_id', 'page', or 'page_size'. This fails to compensate for the missing schema descriptions, leaving parameter semantics underdefined.

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?

Description clearly states the verb 'Search', the resource 'tables', and specifies the matching method (substring in code or name, case-insensitive). This differentiates it from list_tables and get_table, making the tool's purpose immediately 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?

No guidance is given on when to use this tool versus alternatives like list_tables or search_columns. The description implies usage for substring-based lookup but does not state exclusions or conditions, leaving the agent to infer appropriate contexts.

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 must carry the behavioral burden. It does disclose that the operation replaces the existing primary key and that composite columns are supported, which gives some meaningful behavioral context. However, it omits details about destructive consequences, whether dry_run affects behavior, failure conditions, or what happens to dependent schema objects.

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

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

The description is a single lean sentence that front-loads the core action ('replaces the table's primary key with the given columns' before adding the composite note). No words are wasted and the alias reference is useful context rather than filler.

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

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

This is a mutation tool with no annotations, no output schema, and five parameters with zero schema descriptions. The description explains the primary function but is missing important context: what dry_run does, how table_ref identifies the table, whether the operation fails or succeeds when no primary key exists, and what response to expect. An agent gets too little context to call it safely.

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 by explaining parameters beyond their names. The description only clarifies the meaning of 'columns', especially composite support, leaving model_id, table_ref, name, and dry_run entirely unexplained. This partial compensation warrants a low score.

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 ('replaces') and resource ('the table's primary key'), and further clarifies that it is an alias of create_primary_key, which differentiates it from sibling tools. Composite key support is also stated. This is enough for an agent to know exactly what operation is performed.

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 saying the tool replaces the primary key, but it gives no explicit guidance on when to choose set_primary_key versus create_primary_key or remove_primary_key. It doesn't state whether this is the preferred tool when a key already exists, nor does it mention any exclusions or alternatives beyond the alias mention.

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