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

No annotations are supplied, so the description carries the full behavioral burden, yet it only implies a write via the word 'Add'. It says nothing about required Dataverse privileges, that the new column is immediately persisted to the table's schema, or that some choices (e.g. DateTimeBehavior) are effectively irreversible.

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

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

A single front-loaded sentence with zero waste. It is efficient, though its brevity is closer to under-specification than to disciplined conciseness, which caps it below a 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 schema-mutating tool with a nested object parameter, no annotations and no output schema, the description omits permissions, side effects, error conditions, and any hint about how the required nested attribute fields must be combined. An agent cannot call this confidently from 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?

Top-level schema coverage is only 50% (attribute has no description; entity_logical_name does), and the description contributes no parameter detail. However, the nested attribute object documents its own fields thoroughly, including mutual exclusivity of options vs global_option_set and defaults, so the schema largely 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?

States a specific verb+resource ('Add a column (attribute) to an existing Dataverse table'), which maps cleanly onto the tool name and distinguishes it in kind from delete_attribute and update_attribute. It does not name or contrast those siblings explicitly, but the operation 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?

No when-to-use guidance, no mention of prerequisites (the table must already exist, the attribute logical name must be unique), and no routing to alternatives such as update_attribute for modifying an existing column or add_picklist_option for extending a choice 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, the description carries the full burden and delivers meaningful behavior: the unique index is built asynchronously and the key is unusable for keyed lookups until EntityKeyIndexStatus is 'Active'. It omits auth/permission requirements and failure modes (e.g. duplicate data), keeping it from a 5.

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 tight sentences ordered purpose → use cases → critical caveat. The async warning is front-loaded with a NOTE marker, and every sentence carries non-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 mutation tool with no annotations and no output schema, the description supplies the crucial async/lifecycle context and the polling path. It does not address required permissions or how create failures surface, leaving a small gap.

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

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

Schema coverage is 100%, so all five parameters are already documented in the schema. The description reinforces key_attributes (composite support) but adds no syntax or format detail beyond what the schema provides, so the baseline 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?

Starts with a specific verb+resource ('Create an alternate key on a Dataverse table') and immediately clarifies the composite-key capability. It is clearly distinguishable from siblings like add_attribute, add_picklist_option, and create_relationship, which create different object types.

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 two use cases ('race-safe upserts via keyed-PATCH' and 'enforce a uniqueness constraint that the primary key doesn't cover') and routes the agent to list_entity_keys for polling. It stops short of an explicit when-not-to-use, so it lands just below the top tier.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral trait — the authorization requirement and the HTTP 403 consequence — which is real value. But it says nothing about what happens on duplicate labels, whether the option is immediately visible, or what the call returns, leaving significant gaps 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?

Two compact sentences, front-loading the core purpose before the permission caveat. Every clause earns its place; 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?

The description covers purpose and authorization, and the schema fully documents inputs, but with no annotations and no output schema the agent still cannot tell what the call returns (e.g. the assigned option value) or whether the change is persisted to a solution. Adequate but not 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 100%, so the schema already explains all eight parameters including the value-range constraint and the option_set_name vs entity/attribute mutual exclusivity. The description only echoes the Local/Global distinction already captured in the schema, adding no new parameter-level meaning. Baseline 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?

States a specific verb (add) and resource (option to an existing Local or Global OptionSet), and even names the underlying Dataverse action. It is clearly distinguishable from sibling update_picklist_option and delete_picklist_option, which modify or remove existing options.

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 (create a new option rather than modify one), and the description usefully states the required Customizer/System Administrator role and the 403 failure mode. However, it never explicitly contrasts this with update_picklist_option for existing options, nor states any other preconditions 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?

No annotations are provided, so the description carries the full behavioral burden and largely fails: it does not state that this is an irreversible schema mutation, whether it requires specific privileges or an unmanaged solution context, whether the entity and its attributes are created atomically, or what happens on partial failure. Only the bare act of creation is conveyed.

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

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

A single, front-loaded sentence with no filler or repetition. It is efficient, though arguably terse to the point of under-specification rather than over-specification.

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 high-impact schema-mutation tool with no annotations, no output schema, and eight parameters including a nested attribute list, the description is too thin. An agent would want to know about irreversibility, solution/publisher scoping, and creation semantics, none of which are covered.

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 like logical_name, ownership_type, and the nested attribute definitions are already documented in the schema; baseline 3 applies. The phrase 'with specified attributes' nods at the attributes array but adds no meaning beyond the schema's own descriptions 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 gives a specific verb and resource ('Create a new Dataverse table (entity)'), and the parenthetical distinguishes entity from its siblings like create_record, add_attribute, and delete_entity. It stops short of explicitly naming an alternative tool, so it is clear but not fully sibling-differentiating.

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 add_attribute, create_record, or create_relationship, nor any prerequisite (e.g., that a publisher prefix and target solution context are needed). The agent must infer usage entirely from the name and schema.

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, yet it discloses nothing about side effects, required permissions, whether the call is idempotent, or what happens on duplicate/conflicting data. For a mutation tool this is a significant gap, though 'Create a new record' at least correctly signals a write rather than a read.

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

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

A single short sentence with no waste and the verb front-loaded. It is efficient, but the brevity is partly under-specification rather than disciplined conciseness, so it does not reach a 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?

This is a mutation tool with no annotations and no output schema, and the description says nothing about return values, error behavior, or permission requirements. The fully-covered input schema compensates for parameter documentation but not for the behavioral context an agent needs before performing a write.

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%: both entity_set (plural entity set name with examples) and data (key-value record fields) are documented in the schema itself. The description adds no syntax, format, or constraint detail beyond that, so the baseline 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?

States a specific verb (Create) and resource (a new record in a Dataverse table), so an agent immediately knows this is the write counterpart to get_record/update_record/delete_record. It stops short of explicitly naming a sibling or distinguishing its scope from create_entity, which operates on table metadata rather than rows.

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 the many siblings (update_record, create_entity, query_records), nor any stated prerequisites such as required permissions or the need for a valid entity_set. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full behavioral burden, yet it discloses nothing beyond the implied mutation. It does not mention required privileges, whether the relationship can be removed (no delete_relationship sibling exists), what happens if the relationship already exists, or the implications of choosing a relationship type.

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 efficient sentence with zero waste and the core action front-loaded. It is concise, though arguably too terse for a six-parameter metadata mutation tool, keeping it just below a perfect score.

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 absence of annotations and no output schema, the description should compensate with behavioral and usage context. Instead it provides only a one-line purpose, leaving significant gaps around permissions, reversibility, and relationship-type implications for an agent to infer.

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 schema already documents all six parameters, including the OneToMany-only nature of lookup_name and lookup_display_name and the enum for type. The description adds no additional parameter meaning, which matches the baseline of 3 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 states a specific verb ('Create') and resource ('relationship between two Dataverse tables'), making the tool's purpose immediately clear. It does not, however, explicitly differentiate this tool from siblings like add_attribute or create_entity, so it falls short of the 5-level criterion for sibling differentiation.

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

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

The description provides no when-to-use guidance, prerequisites, or alternatives. It does not say when to choose OneToMany versus ManyToMany, nor when to use this tool instead of manually adding attributes. This is a bare purpose statement with no usage direction.

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

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

With no annotations, the description carries the full burden, and it does disclose one important behavioral fact: the tool is disabled for safety. However, it omits the destructive/irreversible nature of dropping a column, what happens to existing data, and any permission requirements for when it is re-enabled.

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

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

A single front-loaded sentence with zero filler; the safety caveat is placed where it will be read. 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 destructive two-parameter mutation with no annotations and no output schema, the description covers the headline fact (disabled) but leaves the agent without the irreversibility/permission context it would need if the tool were active. Adequate minimum, 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 100%, so both parameters are already documented as logical names for the entity and column. The description's use of "column" and "table" only loosely maps to attribute_logical_name and entity_logical_name, adding little 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 names a specific verb and resource (delete a column from a Dataverse table), which distinguishes it from sibling mutations such as delete_entity_key, delete_picklist_option, and delete_record. It stops short of explicitly naming which sibling to prefer, but the scope 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?

"Currently disabled for safety" is valuable usage information telling the agent the call will not succeed, but it gives no alternative path (e.g. update_attribute or a migration route) and no stated conditions under which deletion would be appropriate. Usage is implied rather than specified.

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 notes the tool is 'currently disabled,' which is a valuable behavioral disclosure, but for a destructive mutation tool it says nothing about irreversibility, permission requirements, or what happens to dependent records when an alternative key is removed.

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 that front-loads the action. The parenthetical is efficiently placed. Slightly underspecified rather than bloated.

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

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

A destructive mutation tool with no annotations and no output schema needs to carry more of the burden: irreversibility, permissions, prerequisite lookups. The 'disabled' note is the one piece of essential behavior it does include, leaving several 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%, so both parameters are documented in the schema; the description adds no syntax, format, or naming-convention detail beyond what the schema provides. Baseline 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?

Specific verb (delete) + resource (alternate key) + platform (Dataverse table), which distinguishes it from sibling delete_attribute and from add_entity_key. The parenthetical '(currently disabled for safety)' adds a meaningful operational qualifier.

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 guidance, no routing to alternatives (e.g., list_entity_keys to find key names before deletion). The 'disabled for safety' note implies the tool won't work, which is critical context, but it doesn't explain under what conditions one would attempt this.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one meaningful behavioral trait — the tool is currently disabled — which is genuinely useful for an agent. However, it says nothing about the destructive permanence of removing an option, whether existing records holding that value are affected, or required 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?

A single sentence that front-loads the operation and the resource, with the critical disabled-status caveat attached rather than buried. Nothing is wasted.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers purpose and disabled status but leaves the destructive consequences, permission requirements, and the reason for the disable unexplained. The schema covers parameter semantics well, so the gap is behavioral rather than structural.

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 every parameter (value, option_set_name, entity_logical_name, attribute_logical_name, solution_unique_name) is already documented, including the mutually exclusive pairing rules. The description adds no parameter meaning beyond what the schema provides, so the baseline 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?

States a specific verb (Remove) and resource (an option from a Local or Global OptionSet), and the parenthetical scope note distinguishes it from add_picklist_option and update_picklist_option in the sibling list. An agent can identify the operation without opening the 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 '(currently disabled for safety)' note implicitly tells the agent not to rely on this tool, and the schema covers the Local-vs-Global mutually exclusive paths. But there is no explicit when-to-use guidance, no statement of what to do instead, and no prerequisites (permissions, solution context) called out.

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, and it does disclose one important trait: the operation is disabled for safety. Beyond that it is silent on permission requirements, reversibility, and the failure mode an agent will actually observe when calling it, leaving meaningful gaps for a destructive 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 compact sentence with the operation front-loaded and the critical disabled status attached inline. It is not padded, though the parenthetical could have been a clearly separated clause for faster scanning.

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 two-parameter tool with no annotations and no output schema, the description covers the core fact (disabled) but omits permission requirements, expected error behavior, and any alternative path. It is minimally adequate rather than 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 100% (id as Record GUID, entity_set as Entity set name), so the schema already fully documents both parameters. The description adds no syntax, format, or constraint information beyond the schema, matching the baseline of 3.

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

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

The description states a specific verb and resource ("Delete a record from a Dataverse table"), making the operation immediately identifiable and distinguishing it from record-mutation siblings like create_record/update_record. It does not explicitly contrast against adjacent delete tools such as delete_attribute, so it stops short of a 5.

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

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

The parenthetical "currently disabled for safety" implicitly signals the tool should not be invoked, which is a usable constraint. However, there is no explicit when-to-use guidance, no routing to alternatives for retiring data, and no statement of what the agent should do 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?

No annotations exist, so the description carries full burden and does disclose key traits: best-effort name resolution with nulls, and the backing implementation (RetrieveDependenciesForDelete). It doesn't state permissions/auth needs or output shape, but the null-resolution caveat and the underlying function name give meaningful behavioral context beyond what the empty annotation set provides.

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 tight sentences, front-loaded with the verb and scope, then usage triggers, then a caveat. Every clause earns its place; nothing is redundant.

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

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

For a read-only dependency-lookup tool with no annotations and no output schema, the description covers purpose, triggering conditions, and a name-resolution caveat. It could say more about the failure-mode semantics (why 0x8004f01f means dependencies exist) but is sufficient to invoke correctly.

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

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

Schema coverage is 100% – both parameters are fully described in the schema (logical names of entity and column). The description adds no format/syntax detail beyond the schema, so baseline 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?

States a specific verb (List) and resource (CRM components that reference a column) and enumerates the component types (forms, views, workflows, business rules, plugins). This is clearly distinguishable from siblings like delete_attribute or update_attribute without opening any 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 explicit trigger conditions: 'when delete_attribute fails with 0x8004f01f' and 'before any destructive change to a column.' This ties directly to sibling tools (delete_attribute, update_attribute) and tells the agent exactly when to reach for this tool versus proceeding.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose a concrete output trait — choice-style columns carry an option_set summary with is_global and option_count — which is genuinely useful. However, it says nothing about pagination, permissions, or how large tables are handled, leaving meaningful gaps.

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

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

Three compact sentences, front-loaded with the core purpose, then the choice-column detail, then the handoff to a sibling. Every sentence 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?

With no output schema, the description must convey the return shape; it covers the choice-column case well but is silent on the general shape of returned attribute metadata (types, required flags, etc.). For a single-parameter read tool with no annotations this is close to, 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?

Only one parameter and schema description coverage is 100%, so the schema already documents entity_logical_name with examples. The description adds no naming-format or syntax guidance beyond that, which is the expected baseline when the schema does the work.

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: 'Get attributes (columns) of a specific Dataverse table.' An agent can distinguish this from data-reading siblings (get_record, query_records) and from list_entities, though the distinction is implied rather than stated. It also explicitly positions get_picklist_options as a complementary tool.

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

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

Provides clear context for when this tool pays off ('one dump shows which choice lists are shared org-wide') and routes to get_picklist_options when per-column option values are needed. It lacks an explicit when-not or prerequisite statement (e.g., needing an existing connection/solution), 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, the description carries the full burden. It adds real value by disclosing the return structure (no output schema exists) and the subtle caveat that matching values alone don't prove a Global OptionSet binding, but it omits permissions, error behavior, and what happens on ambiguous local/global inputs.

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?

Front-loads the verb and return shape, then adds the interpretive caveat in a tight second sentence. Dense but every sentence earns its place; 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?

Since there is no output schema, the description correctly compensates by spelling out the response shape and the meaning of is_global. Given no annotations, it could say more about read-only safety, but nothing essential for calling the tool 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 coverage is 100%, so baseline is 3. The description goes beyond it by clarifying the local-vs-global distinction behind the two parameter groups (option_set_name vs entity/attribute pair) and naming the attribute types the third parameter applies 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?

States a specific verb+resource ('Read a Local or Global OptionSet') and even gives the exact return shape, so the operation is unambiguous. It does not explicitly name its sibling mutations (add/update/delete_picklist_option), but 'Read' distinguishes it well enough in context.

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 when-not-to-use guidance relative to alternatives such as get_entity_schema or get_attribute_dependencies. The only implied scope is 'Works for Choice, Status, State and MultiSelect columns', which describes applicability rather than 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?

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, but there is no mention of permissions required, behavior on a missing/invalid GUID, throttling, or whether a null/error is returned — significant gaps for a tool with 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?

A single front-loaded sentence with zero waste. It is appropriately sized, though its brevity is arguably under-specification rather than true 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?

For a simple single-record read with all four parameters documented in the schema, the essentials are present. With no output schema and no annotations, the description could still say what the response contains or how errors surface, so it is only minimally adequate.

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 schema already documents id, entity_set, expand, and select. The description adds no syntax or format detail beyond that, so the baseline 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 states a specific verb (Get) and resource (a single record) scoped by ID from a Dataverse table, which implicitly separates it from query_records (bulk) and the create/update/delete siblings. It does not explicitly name or contrast with any sibling, so it falls short of a 5.

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

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

There is no when-to-use guidance: nothing says to prefer this over query_records when you lack an ID, nor what to do if the record is missing. The only usage signal is the phrase 'by ID', which the agent must infer from.

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 HTTP verb (POST), that it is a mutation-style call, how binding is determined ($metadata), the entity_set+id pairing rule, and that parameters become the request body, plus the bare-vs-fully-qualified name override. It stops short of permissions, error behavior, or return shape, which keeps it out of the top band.

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

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

Three tight sentences, front-loaded with purpose before mechanics. Every clause carries actionable information — no filler, no restatement of the tool name.

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

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

For an open-ended POST-invocation tool with no annotations and no output schema, the description covers invocation semantics thoroughly enough to call it correctly. The one remaining gap is what comes back (arbitrary action responses), though with no output schema and free-form payloads that is hard to specify usefully.

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, but the description adds a genuine cross-parameter constraint the schema states only per-field: 'Pass entity_set+id for bound actions, neither for unbound.' The namespacing override note and the body-mapping note are reinforced but largely duplicate 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 verb and resource ('Invoke a Dataverse Web API action (POST)') plus the bound/unbound axis, and explicitly positions itself against plain CRUD. An agent can distinguish it from create_record/update_record and the other siblings without opening the 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 a clear selection rule — 'use for operations that are not plain CRUD' — with concrete examples (PublishDuplicateRule, QualifyLead, UnpublishDuplicateRule) and the mechanical rule for bound vs unbound calls. It does not explicitly route the agent away from the closely-related invoke_function sibling, which is the one ambiguity left.

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 HTTP method/read-only nature, how parameters are inlined as OData arguments, and the binding requirements. It omits auth/permission needs, error semantics, and return shape for a tool with no output schema.

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

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

Three tight sentences with no filler, front-loading the verb/resource and the GET/read-only constraint before the usage and parameter rules. Every sentence carries instructional 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 four-parameter tool with a nested object parameter, no annotations, and no output schema, the description covers binding, call shape, and argument encoding adequately. It leaves the return payload undefined, which is a real gap only because no output schema exists to compensate.

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 schema already documents all four parameters including the binding conditions and quoting rules. The description restates the entity_set+id binding rule and the OData inlining behavior, adding reinforcement but little genuinely new semantics 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 and resource ('Invoke a Dataverse Web API function (GET)') and its scope (bound or unbound), which separates it from mutation tools. However, it never explicitly names the sibling 'invoke_action' as the alternative for side-effecting operations, leaving the contrast implicit through '(GET)' and 'read-only'.

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 selection criteria: use for read-only operations exposed as functions, with concrete examples (WhoAmI unbound, RetrieveDuplicates) and the bound-vs-unbound parameter rule ('Pass entity_set+id for bound functions, neither for unbound'). It stops short of stating when NOT to use it (e.g. for actions/updates, use invoke_action).

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, yet it discloses nothing about pagination, result ordering, permissions, or the fact that a default solution filter is silently applied when 'solution' is omitted. That default-filter behavior is material to interpreting results and is only visible in the schema, not 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?

A single front-loaded sentence naming the resource and both filters, with no filler. It is tightly sized, though the terseness leaves room for the missing behavioral detail noted elsewhere.

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-optional-parameter read-only listing tool with full schema coverage and no output schema, minimal description is tolerable. However, with zero annotation coverage the description should at least confirm read-only semantics and the default solution filtering, neither of which it provides.

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 both parameters (prefix, solution) already document their formats, env-var fallbacks, and the empty-string escape hatch. The description merely names 'prefix and solution filters' without adding meaning, so the baseline 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?

Specific verb+resource: 'List Dataverse tables (entities)' clearly states the operation and target. It is distinguishable from siblings like get_entity_schema (single-table detail) and list_solutions, though it never names an alternative. Clear but without 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?

The description gives no when-to-use or when-not-to-use guidance and never mentions the alternatives (get_entity_schema, list_solutions) an agent must choose between. Filtering hints ('optional prefix and solution filters') describe capability, not usage conditions.

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, so the description carries the burden, and it adds real behavioral context: the returned fields and crucially that alt keys are not usable until index status is Active. It doesn't cover auth/permissions or whether this is a safe read (implicitly read-only by name), so short of full disclosure.

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

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

Two tight sentences, front-loaded with purpose, then return shape, then the critical index-status caveat. 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 one-param read tool with no output schema, it adequately describes the return array and a key operational constraint. Missing only error/edge-case behavior (e.g., unknown table) and explicit read-only assurance.

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 a single well-documented parameter, so baseline is 3. The description adds no extra syntax or format detail for entity_logical_name beyond what the schema provides.

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

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

Specific verb+resource: 'List alternate keys defined on a Dataverse table', with a precise return shape. Distinguishes from siblings like get_entity_schema or list_entities by naming the exact sub-resource (alternate 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?

Implied usage (inspect keys before composing a keyed-PATCH upsert), but no explicit when-to-use vs alternatives such as get_entity_schema or add_entity_key. The index-status note hints at a precondition but doesn't state how or when to call 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 behavioral burden, and it discloses almost nothing: no read-only confirmation, no permissions, no return shape or pagination. The only behavioral fact (default excludes managed solutions) already lives in the schema, not 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?

One short sentence with a front-loaded verb+resource and a compact parenthetical. Efficient, though the parenthetical is slightly cryptic about what exactly is returned.

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 read tool with no output schema, the description is adequate but thin: it never states what a listed solution contains (names, uniquenames, managed flags), which matters since no output schema documents the return.

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?

There is a single parameter with 100% schema description coverage, so the schema already explains include_managed and its default. The description adds no syntax or semantics beyond that, making the baseline 3 correct.

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

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

States a specific verb and resource: 'List Dataverse solutions'. The parenthetical ties it to list_entities, hinting at its role in the tool family, though it does not fully distinguish it from other listing siblings such as list_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 parenthetical implies a workflow (list solutions to obtain a uniquename, then pass it to list_entities), which is useful implied usage. However, there is no explicit when-to-use/when-not guidance and no named alternative to pick 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, the description carries the full behavioral burden and discloses very little. It does not state the return shape (a collection of records), default/actual paging behavior, server-side row limits, error behavior on invalid filters, or auth requirements. 'OData filters' is the only behavioral hint.

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

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

A single front-loaded sentence with zero filler; the verb, resource, and filtering mechanism come first. Nothing is wasted or buried.

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 six-parameter, no-annotation, no-output-schema tool, the description is too thin: it omits return structure, paging defaults, and when to prefer it over get_record or the write siblings. An agent could call it, but only by inferring everything from parameter names.

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 all six parameters (including required entity_set with a plural-name example) are documented in the schema itself. The description adds 'OData filters' framing but no syntax, escaping, or format details beyond what the schema already provides, so the baseline 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?

States a specific verb ('query'), resource ('records from a Dataverse table') and a distinguishing mechanism ('OData filters'), which separates it from single-record siblings like get_record. It does not, however, explicitly name any sibling or scope (e.g. all records vs. filtered), so differentiation is implicit.

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 over get_record, list_entities, or invoke_action, nor any stated prerequisites (auth, permissions, table existence). The mention of OData filters hints at the intended use case but does not constitute routing guidance.

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

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

With no annotations the description carries the full burden, and it discloses real constraints: type/logical-name immutability and the Dataverse migration path. It stops short of stating whether unspecified fields are left unchanged, permission/auth requirements, or reversibility of other edits, so it is strong but not exhaustive.

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, zero padding: the mutable-field summary is front-loaded and the immutability/migration caveat follows. 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 14-parameter mutation tool with no annotations and no output schema, the description plus rich schema covers the essentials — what can change, what cannot, and the workaround. Missing only operational context like auth requirements and post-update 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 100%, so every parameter is already documented in the schema, including enums and the one-way date_behavior lock. The description's field list merely restates those parameters and adds no syntax or format detail beyond them.

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 (Update) and resource (metadata of an existing column) and enumerates the mutable fields, immediately distinguishing it from add_attribute and delete_attribute.

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 what cannot be done (type and logical name are fixed at creation) and supplies the exact alternative workflow — add_attribute, migrate with update_record, then delete_attribute. An agent knows both when to use this and when to route elsewhere.

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 usefully discloses the required role/permission, which is real auth context. However, it omits behavioral traits such as whether the change replaces all localized labels, solution/transport implications, and reversibility (the merge/replace nuance lives only in the schema).

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

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

Two tight sentences with the action and scope front-loaded, followed by the permission prerequisite. No filler, nothing redundant.

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

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

For a nine-parameter mutation tool with no annotations and no output schema, the description supplies purpose and the key role requirement while the rich schema covers parameter semantics. Missing only peripheral context like preconditions (option must exist) and solution-scoping behavior, so it is largely 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 100%, so the schema fully documents all nine parameters (including the subtle merge_labels replace-vs-merge semantics and the mutually exclusive option_set_name vs entity/attribute pairing). The description adds no parameter-level meaning beyond re-mentioning label/description, 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 states a specific verb (Update) and resource (an existing option's label/description) and scopes it to Local or Global OptionSet, plus names the underlying Dataverse action. It does not explicitly differentiate itself from siblings like add_picklist_option or delete_picklist_option, but the mutation target 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?

It gives one real prerequisite (Customizer or System Administrator role) and identifying context (Local vs Global OptionSet), but never states when to choose this over add_picklist_option or delete_picklist_option, nor what conditions must hold (e.g., option must already exist). Usage is implied rather than guided.

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 implies a mutation but does not state whether the update is partial or full (the 'data' field hints at partial, but the description never confirms), what permissions are needed, what happens if the record id does not exist, or whether changes are reversible.

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

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

A single short sentence with zero waste, front-loading the action and resource. It is appropriately sized even if arguably too thin to be maximally 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 mutation tool with no annotations, no output schema, and a nested free-form data object, the description is inadequate. It never explains update semantics (partial vs replace), error behavior, or return shape, leaving the agent to guess at call 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 100%, so the schema already documents id (GUID), entity_set (plural set name) and data (key-value fields to update). The description adds nothing 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?

States a specific verb (Update) and resource (an existing record in a Dataverse table), which is enough to tell it apart from create_record, delete_record and get_record by verb alone. It is clear but adds no sibling differentiation beyond the verb, and says nothing about the table/entity scope beyond 'Dataverse table'.

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 guidance, no exclusions, and no mention of alternatives such as update_attribute or create_record. The agent must infer that this is the write path for an existing row purely from the name.

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