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 only says 'Add' without revealing mutation side effects, irreversibility, solution/publishing requirements, or failure conditions. Notable behavioral constraints like the one-way date_behavior change are hidden in the schema, not in the description.

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 or redundant restatements. Every word earns its place, and the core action and target are clear immediately.

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 nested attribute schema captures most configuration semantics, making the tool relatively self-contained. However, the description omits any context about prerequisites (e.g., table existence), publishing/deployment behavior, or what happens after the operation. With no output schema and no annotations, those gaps make the description only minimally complete.

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

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

The description itself provides no parameter-level meaning, but the input schema includes descriptions for all visible properties, including nuanced semantics like mutual exclusivity of options and global_option_set, plus DateTime behavioral details. Since the schema does the heavy lifting, the description adds only marginal value here.

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 verb ('Add'), a specific resource ('a column/attribute'), and a target context ('an existing Dataverse table'). This distinguishes it from create_entity (creating tables) and create_relationship, and the sibling list confirms the category of attribute tools.

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

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

The description implies the tool is for adding attributes to an existing table, which is enough to infer the basic use case. However, it does not explicitly say when to prefer this over update_attribute or other alternatives, nor does it mention any 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 must disclose side effects and behavioral traits. It does so by warning that the supporting unique index is built asynchronously and the key is unusable until EntityKeyIndexStatus becomes 'Active', plus the need to poll. This is important behavioral context beyond the schema. However, it does not mention permission requirements or behavior on duplicate keys, so a small gap remains.

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

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

The description is concise and well-structured: three sentences covering purpose, use cases, and a critical asynchronous caveat. No redundancy, every sentence adds value, and the most critical operational detail is placed 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 the tool's complexity and lack of annotations/output schema, the description is notably complete. It covers what the tool does, when to use it, and the essential post-creation step (polling for active status). It effectively compensates for missing structured metadata and provides enough context for 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?

The input schema provides 100% parameter coverage with descriptions for every parameter, including examples and constraints. The description adds little new parameter-specific meaning beyond mentioning composite support via key_attributes, which the schema already explains. Thus, the baseline 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 clearly states the action and resource: 'Create an alternate key on a Dataverse table' and explicitly mentions composite key support via key_attributes. It distinguishes itself from sibling tools like list_entity_keys and delete_entity_key by focusing on creation, with use cases that are unique to this 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?

It provides explicit guidance on when to use the tool: 'Use for race-safe upserts via keyed-PATCH or to enforce a uniqueness constraint that the primary key doesn't cover.' It also suggests a follow-up action (poll with list_entity_keys) which is valuable operational guidance for the agent.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does state required roles and the HTTP 403 consequence, which is valuable. However, it does not disclose other behavioral aspects such as side effects, reversibility, or return format. The permission context is helpful but coverage is partial.

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, no filler. It front-loads the primary action and then adds the crucial permission requirement. 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?

The tool has 8 parameters and no output schema, so the description should ideally provide more guidance on expected outputs or when to choose certain parameter combinations. While the schema is comprehensive, the description is minimal and does not explain return values or possible pitfalls. It is adequate but not fully complete for a complex 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 100%, so the parameters are fully documented in the schema. The description adds no extra parameter-specific guidance beyond what is already in the schema, such as the mutual exclusivity of option_set_name vs entity_logical_name, which is already present in the schema properties.

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

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

The description clearly states the action: 'Add an option to an existing Local or Global OptionSet' with a specific verb and resource. It distinguishes itself from sibling tools like update_picklist_option and delete_picklist_option by focusing on the 'add' operation, and also specifies the Dataverse action.

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 implies when to use it (adding a new picklist option), but it does not explicitly mention alternatives or exclusions. There is no statement like 'for updating existing options, use update_picklist_option instead.' The usage is implied but not explicitly contrasted with 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?

There are no annotations, so the description must disclose behavioral traits on its own. It only states the action without revealing side effects such as provisioning time, potential validation failures, or whether the operation is asynchronous. While not misleading, it is far from 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?

One short, front-loaded sentence with no wasted words. It states exactly what the tool does without redundancy, earning a top score for efficiency.

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 schema is exceptionally rich, covering parameter types, dependencies, and side-effect warnings (e.g., one-way date_behavior). The description itself is too thin to be fully self-sufficient, but when combined with the schema, an agent has nearly everything needed. Still, it could mention high-level constraints like permission requirements or the structural impact of creating an entity.

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 100% description coverage, including detailed comments on enums, mutual exclusions, and defaults. The description itself adds no parameter detail, but the schema already carries the weight, fitting the baseline-3 rule for high coverage.

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

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

The description uses a clear verb + resource structure: 'Create a new Dataverse table (entity) with specified attributes.' It unambiguously distinguishes itself from sibling tools like create_record or add_attribute by naming both the table and the ability to pass attributes in the same call.

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 when-to-use or when-not-to-use guidance is provided. The description does not mention how this tool relates to create_record or add_attribute, and there are no exclusions or alternative scenarios to help an agent decide between them.

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 only states the core mutation action ('create') without detailing permissions, validation behavior, error handling, or response format, which leaves significant gaps for an agent.

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 target. No words are wasted, and it is 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?

For a simple 2-parameter tool with full schema coverage and no output schema, the description is minimally adequate. However, it lacks usage guidance and does not indicate what the response will be, leaving some contextual 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 100%, with both parameters well-described (entity_set with plural example, data as key-value pairs). The description adds no extra parameter context beyond the schema, so the baseline 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 'Create a new record in a Dataverse table' uses a specific verb ('create') and resource ('record in a Dataverse table'), clearly distinguishing it from sibling tools like update_record and delete_record.

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

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

No guidance is provided about when to use this tool versus alternatives such as update_record or create_entity. It does not mention prerequisites, exclusions, or scenarios where another tool would be 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Create a relationship,' which implies mutation but does not describe side effects, permissions, reversibility, or validation behavior. For a write operation, this is a significant transparency gap.

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

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

The description is a single, well-structured sentence with no filler. It is front-loaded and concise, though it is extremely minimal and could benefit from slightly more detail without sacrificing conciseness.

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 6 parameters (4 required) and no output schema or annotations, but the description provides only a one-line purpose. It does not explain relationship types, prerequisites, side effects, or what happens on success/failure. This is incomplete for an agent to fully understand the tool's 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?

The schema description coverage is 100%, meaning every parameter has its own description within the input schema. The tool description adds no parameter-specific meaning beyond the overall context, so the baseline score of 3 applies.

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

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

The description clearly states the tool's purpose: 'Create a relationship between two Dataverse tables.' This uses a specific verb ('create') and resource ('relationship between two Dataverse tables'), distinguishing it from sibling tools like create_entity or add_attribute, which create different types of metadata.

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, nor are there any exclusions or prerequisites mentioned. The description only states what the tool does, offering no contextual decision-making information.

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 is disabled for safety, which is important behavioral context. However, it does not mention the destructive nature of deletion, potential irreversibility, or dependency implications, leaving significant 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, focused sentence that front-loads the action and includes a relevant safety note. There is no unnecessary filler, making it highly concise and well-structured.

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

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

The tool is simple (2 params, no output schema), and the description covers the core purpose and disabled status. However, it lacks important context about dependencies and consequences, especially given the presence of get_attribute_dependencies as a sibling, making it only partially 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 covers 100% of parameters with clear descriptions ('Logical name of the entity' and 'Logical name of the column'). The description adds no additional semantic value beyond the schema, so the 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 clearly states the action ('Delete a column') and the resource ('Dataverse table'), distinguishing it from sibling tools like add_attribute and update_attribute. The additional note about being disabled for safety further clarifies the tool's current 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?

No explicit guidance is given on when to use this tool versus alternatives, such as checking dependencies with get_attribute_dependencies before deleting. The disabled note implies it should not be used currently, but no context or exclusions are provided.

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

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

With no annotations provided, the description carries the full burden. It discloses the disabled state for safety, which is an important behavioral warning. However, it does not mention side effects, permission requirements, or whether deletion is reversible, leaving some 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 one concise sentence with a leading verb and a crucial caveat. No filler or redundant information.

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

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

For a simple two-parameter delete operation, the description plus schema provide enough context. The disabled-state note is essential and addresses the main operational question. It could mention side effects, but for a tool that is disabled, the risk is mitigated.

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 already documents both parameters with clear descriptions (100% coverage), so the description adds no additional parameter semantics. Baseline 3 applies because schema covers parameters completely.

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 the specific verb 'Delete' and identifies the target resource ('alternate key from a Dataverse table'), clearly distinguishing it from sibling tools like add_entity_key and list_entity_keys. It states 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 phrase 'currently disabled for safety' explicitly signals that the tool should not be invoked, which is critical usage guidance. It does not name alternatives, but the context is sufficiently clear; an agent understands not to rely on 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?

With no annotations provided, the description carries the full burden. It discloses the tool's scope and the 'disabled for safety' status, which is valuable, but it does not elaborate on consequences such as irreversibility, impact on existing records, or permission requirements. This leaves gaps for a delete 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 effectively communicates the action, scope, and safety status. No wasted words; the parenthetical 'currently disabled for safety' is important and elegantly placed.

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

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

Given that there is no output schema and the tool is a delete operation, the description is somewhat thin. It lacks information about return values, error behavior, or side effects. The safety warning adds context, but the description could be more complete by noting irreversibility or impact on dependent data.

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

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

The schema provides complete descriptions for all five parameters, including mutual exclusivity constraints. The description adds no new parameter-level semantics beyond the 'Local or Global' distinction, which is already implicitly covered by the schema. Baseline of 3 applies because schema coverage is 100%.

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 ('Remove') and the resource ('option from a Local or Global OptionSet'), distinguishing it from sibling tools like add_picklist_option, update_picklist_option, and get_picklist_options. The scope is explicit, leaving no ambiguity 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 clear context for when the tool is applicable (removing options from Local or Global OptionSets) and importantly warns that it is currently disabled for safety, which serves as a when-not-to-use directive. However, it does not explicitly name alternatives like update_picklist_option or mention 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 mentions 'currently disabled for safety', hinting that calling the tool may fail or be restricted, but it does not explain what actually happens when invoked (error, no-op, partial deletion), nor does it confirm the destructive irreversible nature of a delete operation. The safety note is vague and lacks specifics on permissions or side effects.

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

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

The description is a single concise sentence with no wasted words. It front-loads the primary action and includes a brief warning. It is appropriately sized for a simple tool, though it sacrifices behavioral detail for brevity.

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 mutation with no output schema and no annotations, the description is incomplete. It does not state expected outcomes, error behavior, or the consequences of calling a disabled tool. While the 'disabled for safety' note hints at restriction, it lacks the detail an agent needs to handle the call gracefully (e.g., ignore, expect failure, or seek alternatives). The description is borderline adequate but leaves key gaps.

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

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

Schema coverage is 100%, so the input schema already fully documents both parameters (entity_set and id). The description adds only the high-level context that the record resides in a Dataverse table, which does not meaningfully enhance understanding of the parameters beyond the schema. A baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Delete a record from a Dataverse table'. It specifies the verb (delete) and the resource (record in a table). It is distinguishable from siblings like delete_entity_key because it targets records, not 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 offers no explicit guidance on when to use this tool versus alternatives. The phrase 'currently disabled for safety' implies it should not be used, but it does not mention which sibling tools (e.g., delete_entity_key, update_record) serve as substitutes or what conditions would warrant using this tool. This leaves the agent without clear routing.

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

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

Since no annotations are provided, the description carries the burden, and it delivers by disclosing best-effort behavior, a definite action to trigger it, and its dependency. The only small gap is a lack of detail on error cases (e.g., invalid entity name) and typical return codes, but what is disclosed adds real value.

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

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

Three sentences, each serving a purpose. It's front-loaded with the core function, then usage trigger, reliability caveat, and technical background. No wasted words.

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

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

For a read-only inspection tool with clear parameters and rich context clues, the description is thorough. The single minor gap is not specifying the return shape in case of success or error, but that's partially mitigated by the parenthetical in the description.

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

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

Schema coverage is 100%, so parameters are well-documented; the description doesn't need to repeat them. It adds context by explaining these two parameters uniquely identify the attribute, enhancing understanding beyond a simple 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 is exemplary: it uses a specific verb ('List'), names the resource ('CRM components that reference a column'), and provides concrete examples ('forms, views, workflows...'). It goes further by naming a direct association with a backend function, which uniquely identifies 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?

Explicit guidance is clear: call this tool when deletes fail with a specific error, or as a pre-destructive action. It positions itself as a companion to delete operations, distinguishing it from other tools in the sibling list. No ambiguity.

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 explains that choice-style columns include an option_set summary with is_global and option_count, and it clarifies that actual option values are not returned here, pointing to get_picklist_options. This goes beyond the basic 'get schema' statement and helps the agent set expectations.

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

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

The description is concise and front-loaded with the core purpose. Each sentence adds useful information: the main action, the choice-column behavior, and the follow-up tool for option values. There is no wasted wording.

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

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

For a single-parameter, no-output-schema tool, the description is reasonably complete. It covers what is returned at a high level, highlights notable behavior for choice columns, and points to the relevant sibling tool for further detail. It does not describe error cases or formatting, but those are not critical for this simple lookup 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?

The input schema already fully documents the single parameter with a clear description and example, so schema coverage is 100%. The description does not add much parameter-specific detail, but none is needed because the schema covers it.

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

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

The description clearly states the tool gets attributes (columns) of a specific Dataverse table, using a specific verb and resource. It also distinguishes the tool from list_entities by focusing on a single entity's schema rather than listing entities.

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

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

The description gives useful context on when to use this tool, such as when you need attributes and want to see which choice lists are shared org-wide. It explicitly directs the agent to use get_picklist_options for actual option values, which is a clear alternative. It does not explicitly mention when not to use this tool versus list_entities or get_attribute_dependencies, but the context is strong 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 provided, the description carries the full burden. It discloses the output shape and gives a critical behavioral insight: 'matching values alone do not prove a binding' — a non-obvious trap that could mislead agents. However, it does not address error conditions, permissions, or what happens when required parameters are missing, leaving some gaps for a read operation.

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

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

The description is two sentences with zero waste. The first sentence states the operation and return format; the second explains the critical is_global distinction and lists supported column types. Information is front-loaded and each 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 read tool with three parameters and no output schema, the description covers the essential return structure and the interpretation caveat. It does not explicitly explain that option_set_name OR entity/attribute must be provided, but that is captured in the schema's mutual exclusivity descriptions. The key missing piece is a note on what happens when neither parameter set is given, but overall it is sufficiently complete for the tool's complexity.

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

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

Schema description coverage is 100%, so each parameter's purpose is already documented. The description does not add format or syntax details beyond the schema. It mentions Local vs Global but does not explicitly map them to parameter groups, though the mutual exclusivity is defined in the schema. This meets the baseline of 3 for a well-covered 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 purpose: 'Read a Local or Global OptionSet' and specifies the exact output structure. It distinguishes this read operation from sibling tools like add_picklist_option, update_picklist_option, and delete_picklist_option, which are mutations. The mention of column types (Choice, Status, State, MultiSelect) further narrows the 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?

It provides context about when the tool applies (column types) and how to interpret results (is_global caveat), but it does not explicitly state when to prefer this tool over alternatives, nor does it name exclusions or conditions. The guidance is implied rather than explicit, so it meets the minimum but lacks direct routing to 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 indicates a read-only operation but does not disclose error handling, permission requirements, or return behavior beyond the schema. It provides minimal 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 that conveys the core purpose without unnecessary detail. It is concise and well-structured.

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

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

The tool is a straightforward record retrieval with all parameters described in the schema. However, the description lacks guidance on alternatives and error scenarios, which are not covered by an output schema or annotations. It is minimally 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?

All four parameters are documented in the schema with clear descriptions (GUID, entity set name, expand, select), and the description itself does not add further parameter context. Schema coverage is 100%, so a baseline of 3 applies.

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 target ('a single record by ID'), and the context ('from a Dataverse table'), making it easy to distinguish from sibling tools like query_records which return multiple records.

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 use case (retrieving a record when the ID is known) but does not explicitly contrast with query_records or specify when not to use it. No alternative tools are mentioned.

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 of behavioral disclosure. It reveals that the request is a POST, that parameters become the JSON body, and how binding works. However, it does not mention potential side effects, required permissions, or return value behavior, which are important for a tool that invokes arbitrary actions that may mutate data.

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 four sentences, each earning its place: it names the operation, gives examples, explains boundness, and specifies parameter mechanics. The most critical information (invoke action, POST) is front-loaded, and there is no fluff or repetition of schema details.

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

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

For a tool with no output schema and no annotations, the description covers the essential operation, bound/unbound distinction, examples, and parameter construction. It does not describe return values or error handling, but these are action-specific and would require knowing the individual action. The description is reasonably complete for the tool's complexity.

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

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

The schema already provides 100% coverage with descriptions for all parameters, so baseline is 3. The description adds meaning by explaining the relationship: parameters become the JSON request body, entity_set+id are used for bound actions and neither for unbound. This clarifies the parameter usage beyond the schema's individual property 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 invokes a Dataverse Web API action via POST, with specific examples like PublishDuplicateRule and QualifyLead. It distinguishes from plain CRUD tools by saying 'Use for operations that are not plain CRUD', but does not explicitly name the sibling invoke_function, so the differentiation is implicit rather than explicit.

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

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

The description provides clear usage context: 'Use for operations that are not plain CRUD' and explains bound versus unbound actions with examples. It states when to pass entity_set+id versus neither, giving practical guidance. However, it does not explicitly name alternative tools (e.g., invoke_function for functions) or exclusions beyond the CRUD comment.

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

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

With no annotations provided, the description carries the full burden. It discloses the HTTP method (GET), bound/unbound behavior, and how parameters are inlined into the URL as OData arguments. It does not mention auth/error details, but the core mechanics are transparent and non-contradictory.

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?

Four short sentences, front-loaded with the primary purpose, followed by usage rules and parameter behavior. No filler or redundant content. 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 4-parameter tool with a nested parameters object and no output schema, the description adequately covers bound/unbound usage, URL inlining, and read-only scope. It could mention response format or error handling, but such details are not essential given the absence of an output schema. Overall, highly complete for its complexity.

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

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

Schema coverage is 100% with each parameter already described. The description adds value by explaining the relationship between entity_set and id, and by clarifying that parameters are serialized as OData arguments. This goes beyond the schema's individual field notes.

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 invokes a Dataverse Web API function via GET, with bound/unbound variants. It provides concrete examples (WhoAmI, RetrieveDuplicates) that distinguish it from sibling tools like invoke_action and get_record.

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 states this is for read-only operations exposed as functions, and gives precise instructions on when to pass entity_set+id (bound) versus neither (unbound). This effectively differentiates from invoke_action and data-modifying 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description only mentions listing with filters; it does not state that the operation is read-only, nor does it disclose the env var fallback behavior for parameters (though this appears in the schema), pagination, or output shape. This is minimal 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 that front-loads the action and resource, and then mentions the optional filters. Every word earns its place with no redundancy.

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

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

The tool is simple with two optional parameters and no output schema, so the description is minimally viable. It does not mention important context like the env var defaults (though present in schema), pagination, or whether the entity list includes metadata. Given the lack of annotations, this could be more complete, so a score of 3 is appropriate.

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?

Input schema coverage is 100% with descriptive parameter documentation, including examples and env var fallback behavior. The description adds no extra parameter meaning, but the schema already handles semantics, so the baseline of 3 applies.

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'), the resource ('Dataverse tables (entities)'), and the optional filters ('prefix and solution'). This distinguishes it from siblings like list_solutions (which lists solutions) and get_entity_schema (which retrieves schema for a specific entity).

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

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

Usage is implied: use this tool to list entities. However, no explicit guidance is given on when to prefer this over the many sibling tools that also deal with entities (e.g., get_entity_schema, create_entity). There is no exclusion or alternative named, so the guidance is only implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return format (flat array of fields) and adds significant context about entity_key_index_status reflecting a background index build (Pending → Active, or Failed) and that keys are not usable for keyed-PATCH upserts until Active. This goes beyond a basic listing description.

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, front-loaded with the primary purpose, and the second sentence efficiently adds valuable behavioral context. No wasted words.

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 low complexity (one simple parameter, no output schema, no annotations), the description is quite complete. It covers the action, return fields, and a key behavioral nuance. It could mention error handling or pagination, but for a list tool of this simplicity, it is sufficiently complete.

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

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

The schema already documents the sole parameter 'entity_logical_name' with a clear description. The tool description does not add any parameter-specific meaning beyond what the schema provides. With 100% schema coverage, the baseline 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 uses a specific verb 'List' and clearly states the resource ('alternate keys') and scope ('on a Dataverse table'). It distinguishes itself from sibling tools like add_entity_key/delete_entity_key by focusing on listing rather than mutation.

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 list alternate keys) but does not explicitly name alternatives or provide exclusions. It lacks guidance such as 'for creating or deleting keys, use add_entity_key/delete_entity_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?

No annotations are present, so the description carries the full burden. It only says 'list', implying a read operation, but fails to disclose important behaviors like the default exclusion of managed solutions (which is only in the schema) or any pagination/ordering. For a tool with no annotation support, 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 very brief, which is good for conciseness, but the parenthetical 'uniquename is used to filter list_entities' is a confusing aside that doesn't directly relate to listing solutions. It reads like a fragment or cross-reference that could be better placed in the description of list_entities.

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

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

With no output schema and minimal description, the agent has no idea what the response looks like or what fields are returned. The reference to uniquename without explanation adds ambiguity, and the tool description fails to describe the solution entity's key properties, making it incomplete for a listing 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?

The schema covers the single optional parameter include_managed with a clear description (default false, only unmanaged returned). The tool description adds no additional parameter semantics, so the baseline 3 applies given the high schema coverage.

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

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

The description clearly states the tool 'List Dataverse solutions' with a specific verb and resource. However, the parenthetical 'uniquename is used to filter list_entities' introduces a tangential reference to another tool, which could confuse the primary purpose. Despite this, the main action remains 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 provides a cross-tool hint: if you need to filter entities, use list_entities with uniquename. This implies an alternative usage, but it doesn't explicitly state when to use list_solutions itself, such as when you need an overview of all solutions or to find a solution's uniquename.

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 disclose behavior; it only states 'Query', implying read-only but not explicitly confirming non-destructive behavior or response format. Details like pagination, error handling, and result shape are absent.

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

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

The description is a single concise sentence that front-loads the core purpose. Every word earns its place with no redundancy or filler.

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

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

Given six parameters, no annotations, and no output schema, the description is incomplete. It fails to explain return value structure, pagination behavior, or typical usage patterns that would help an agent invoke the tool correctly.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds no extra parameter semantics beyond mentioning OData filters, which is already present in the filter parameter 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 clearly states a specific verb ('Query') and resource ('Dataverse table') with a scope ('OData filters'). This distinguishes it from sibling tools like get_record (which retrieves a single record) by emphasizing broad querying capability.

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 querying with OData filters but does not explicitly contrast with alternatives such as get_record for single-record retrieval. No clear when/when-not guidance is provided, though context is discernible.

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 crucial constraint that Dataverse fixes type and logical name, and that changing them requires migration via other tools. However, it does not mention other behavioral aspects such as required permissions, immediate effect on data validation, or potential irreversibility beyond type/name (some details exist in the schema for date_behavior but not in the description).

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 zero waste. The first sentence states the purpose and scope; the second sentence front-loads a critical constraint and the alternative workflow. Every sentence earns its place and the structure is highly scannable.

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

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

For a 14-parameter metadata mutation tool with no annotations and no output schema, the description covers the essential context: what can be updated, what cannot be updated, and the recommended alternative for immutable properties. It doesn't explicitly mention permissions or system-level side effects, but the schema covers parameter-specific semantics. Slightly more could be said about operational impact, hence not a 5.

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 100%, so the baseline is 3. The description reiterates which parameters are updatable but adds no new parameter-level semantics beyond the schema's already detailed per-field descriptions. It does clarify the role of 'type' as an immutable constraint, but that is also captured in 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 uses a specific verb 'Update' with resource 'metadata of an existing column' and explicitly lists what can be updated (display name, description, required level, max length, min/max value, precision). It also distinguishes itself from siblings by stating that type and logical name are fixed, guiding users to add_attribute/delete_attribute instead.

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

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

It gives explicit when-to-use and when-not-to-use guidance: for metadata updates use this tool; for type/logical name changes it prescribes the exact alternative workflow (add_attribute → update_record → delete_attribute). It also references add_attribute for date_format semantics, reinforcing the 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 disclosing behavior. It mentions the required role (Customizer or System Administrator) and the Dataverse action, which is useful. However, it does not describe the default label replacement behavior (merge_labels=false) or potential side effects, leaving gaps in transparency.

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

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

The description is two sentences, front-loaded with the core purpose, and adds only the necessary role requirement. No fluff or redundant 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?

Given the tool's moderate complexity (9 parameters, 2 required) and no output schema, the description covers the essential purpose and role but lacks details about default label merging behavior and possible errors. It is adequate but not fully comprehensive.

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

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

The input schema provides 100% coverage of parameter descriptions, including mutual exclusivity and defaults. The description adds no additional parameter-specific semantics beyond what the schema already offers, so the 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 clearly states the verb (update), the resource (existing picklist option), and the scope (Local or Global OptionSet). It explicitly mentions the underlying Dataverse action, distinguishing it from sibling tools like add_picklist_option and delete_picklist_option.

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 clearly implies when to use this tool: when updating an existing option's label/description on a Local or Global OptionSet. It does not explicitly name alternatives or exclusions, but the context and sibling tool names make the use case clear.

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 disclosure. It only says 'update' with no mention of side effects, permissions, partial updates, or failure behavior. For a mutation tool, this is a significant transparency gap.

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

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

The description is a single concise sentence with no wasted words. It is front-loaded with the verb and resource, but is so minimal that it omits useful context, though that is more a completeness concern than a conciseness issue.

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

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

Given that the schema fully documents the parameters and there are no annotations, the description covers the basic purpose but lacks guidance on usage, potential outcomes, and limitations. For a simple CRUD tool this is acceptable but not complete enough to handle edge cases or clarify when to use it.

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

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

The input schema provides complete descriptions for all three parameters (entity_set, id, data), covering 100% of parameters. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 applies.

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 'Update an existing record in a Dataverse table' with a specific verb and resource. It differentiates from create/delete/get through the word 'update', but does not explicitly name alternatives, so it is clear but lacks explicit sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives like create_record or delete_record. The description simply states the action without any prerequisites, exclusions, or alternative references, leaving the agent to infer usage.

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