fix_case_sensitive_dax

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

With no annotations provided, the description carries the full burden. It discloses that the tool rewrites references to exact casing, mentions the specific use case, and states the return value ('Returns the measures rewritten'). However, it does not explicitly warn about the mutating nature of the operation or any side effects (e.g., whether changes are reversible, what happens if references are not found). This is more informative than a bare mutation tool but still lacks comprehensive behavioral disclosure.

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

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

The description is two sentences, front-loaded with the primary action and context. Every clause adds value: the rewrite scope, the use case, and the return value. No redundant wording or irrelevant 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?

The tool has one simple parameter, no output schema, and no annotations. The description explains what it does, when to use it, and what it returns, which covers most operational needs. It does not specify the exact format of the returned measures or any error handling, but these are minor gaps for a straightforward fix tool. Overall, it is sufficiently complete for the 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 input schema contains only 'sessionId' (string, required) with no description, resulting in 0% schema description coverage. The tool description does not elaborate on this parameter. However, 'sessionId' is a common, self-explanatory identifier in the sibling tool list, and the low parameter count reduces the need for compensation. Baseline for low coverage is 2-3; given the trivial nature of the parameter, a 3 is reasonable.

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

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

The description clearly states a specific action ('Rewrite every measure's table / column / measure references') and a specific resource (measures in a DirectQuery/Direct Lake model). It also differentiates from sibling tools by focusing on case-sensitivity fixes, making it distinct from vvalidation tools like 'validate_dax' or general 'dax_suggest_rewrite'.

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

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

The description provides clear context for when to use the tool: 'the fix for DirectQuery / Direct Lake against case-sensitive sources'. It implies the tool is for correcting case-mismatch issues but does not explicitly list exclusions or alternatives. This is clear context without exclusions, matching the '4' descriptor.

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