fabric-dw-mcp-cli

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

No annotations provided, so description carries full burden. It discloses idempotency, immediate effect on live policy, and the eventual consistency risk with clear mitigation advice.

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?

Well-structured with purpose, idempotency, cautions, and args. Efficiently uses sentences without waste, though the args section could be more concise.

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

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

Covers preconditions (auditing enabled), behavioral nuances (eventual consistency), and output schema exists. Does not describe return value, but that is covered by output schema.

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

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

Schema has 0% description coverage. Description lists parameters and gives an example for 'group' (e.g., BATCH_COMPLETED_GROUP), but workspace and warehouse lack any format or context beyond names.

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

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

Description clearly states it adds a single audit action group without overwriting others, distinguishing it from bulk operations. The idempotency note reinforces its specific behavior.

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 auditing must already be enabled and warns about spacing writes due to eventual consistency. However, it does not explicitly contrast with siblings like set_audit_action_groups.

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

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

No annotations are provided, so the description carries full burden. It describes the SQL command executed but does not disclose side effects, permissions required, error conditions (e.g., policy must exist, function must exist), or behavior if predicate already exists.

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

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

The description is well-structured with a one-line summary, a brief explanation, and an Args list. It is front-loaded and concise, with no extraneous 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?

The description thoroughly covers the 8 parameters (7 required) but lacks behavioral context such as prerequisites (e.g., policy must exist) and output details. Since there is an output schema, the absence of return value explanation is acceptable, but more behavioral completeness would improve the score.

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 Args section explains each parameter clearly, including that 'fn_schema' is optional and 'policy_name' should be qualified. It adds meaning beyond the input schema, which has 0% description coverage. The description clarifies that 'fn_args' are column names passed to the function.

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 adds a FILTER predicate to an existing row-level security policy, using the specific SQL command. It distinguishes from related tools like 'drop_security_predicate' and 'create_security_policy'.

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 mentions that there is no predicate-type or operation parameter because Fabric Data Warehouse only supports FILTER predicates, which is a useful caveat. However, it does not provide explicit guidance on when to use this tool versus alternatives or what prerequisites exist.

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

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

Without annotations, the description carries full burden. It discloses the action (assignment) but omits side effects (e.g., overwriting existing assignments), required permissions, or success/failure indicators.

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: one sentence plus brief parameter explanations. No redundant information, ideal for quick parsing.

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

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

Given the tool has an output schema (implied) but the description does not mention return values, error conditions, or prerequisites. For a command-like mutation, important context is missing.

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

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

The description adds minimal value beyond the schema by specifying that workspace can be 'name or GUID' and capacity_id is a 'UUID'. However, it does not explain how to obtain these values or provide constraints, such as format validation.

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 'assign' and the resources 'workspace to Fabric capacity', making the tool's function explicit. It distinguishes from siblings, which are predominantly SQL and table management operations.

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 (e.g., prerequisites like ensuring the capacity exists via list_capacities). There is no mention of conditions or when not to use it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It clearly states what gets destroyed (name-to-UUID cache entries), the available scopes, and the exact return dict keys and their meanings. This gives an agent a solid mental model of the operation's 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 first sentence is a clear, front-loaded summary. The Args and Returns sections are tightly written with no redundant or promotional fluff, and every sentence earns its place by explaining a concrete aspect of invocation or output.

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

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

For a single-parameter tool with an output schema, the description is complete: it covers the parameter semantics, default behavior, and the return contract. Nothing an agent needs to call the tool correctly 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 0% and the only parameter 'scope' is documented entirely in the description. The description explains each enum value ('workspaces', 'items', 'all'), its effect, and the default behavior, adding semantic meaning well beyond the bare schema enum.

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 ('Erase') and a precise resource ('cached workspace and item name-to-UUID mappings'), making the tool's function immediately clear. It is distinct from siblings like clear_table because it targets name-resolution cache entries, not table data.

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 explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It explains what the tool does and the scope options, but usage context (e.g., 'use when cached mappings are stale') is left unstated.

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 provided, but description fully discloses destructive irreversible nature, structure preservation, and platform restrictions. No contradictions.

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?

Well-structured with clear main action, caution, and args list. Front-loaded and every sentence adds value; no unnecessary text.

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 3 parameters and no annotations, description covers all aspects: function, constraints, caution, parameter guidance. Complete for agent to use correctly.

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

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

With 0% schema description coverage, the description explains all three parameters: workspace, item (warehouse), and qualified_name with example. Provides meaning beyond 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?

Description clearly states it truncates a SQL table (removes all rows, keeps structure). Distinct from sibling tools like delete_table, clone_table, etc.

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 only supported on Fabric Data Warehouses, not SQL Analytics Endpoints, and provides caution for destructive irreversible operation, advising user confirmation.

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 disclosure burden, and it does disclose the key behavioral traits: zero-copy semantics, point-in-time behavior, the 30-day retention window, and default to current state when `at` is omitted. It does not cover permissions or failure behavior, but the essential operational traits are present.

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

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

The description is front-loaded with the core purpose, followed by the essential platform caveat and an Arg list that uses compact line-per-parameter formatting. No wasted words; the structure makes scanning easy.

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, platform restriction, and all parameter semantics, and an output schema exists so return values need not be described. It omits edge-case behavior such as whether `new_table` must not already exist, but the overall calling context 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?

Schema coverage is 0%, but the Args block fully compensates: workspace/item are clarified as name or GUID, source/new_table get qualified-name examples, and `at` gets an ISO-8601 format, a retention-window constraint, and default behavior. This is more useful than a typical schema 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 opening line names a specific operation ('Create a zero-copy clone of a table') and the exact SQL construct used (`CREATE TABLE … AS CLONE OF …`). This clearly separates it from sibling table tools like create_table or create_empty_table, even without naming them.

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

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

The description gives a clear platform constraint ('Only supported on Fabric Data Warehouses (not SQL Analytics Endpoints)'), which helps an agent avoid misuse. However, it never explicitly directs when to choose clone_table over create_table/create_empty_table/import_table_from_url; the usage is implied by the 'zero-copy clone' wording.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It reveals the exact query mechanism (`SELECT COUNT_BIG(*)`), the time-travel behavior via `OPTION (FOR TIMESTAMP AS OF ...)`, and the supported platforms. This is meaningful behavioral context beyond the bare input schema, though it could go further on performance or permission implications.

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

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

The description is well-structured and front-loaded with the core purpose. The Args section is compact and every line adds necessary information—parameter meanings, format examples, and time-travel behavior. No filler or redundancy.

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

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

The description covers all parameters, supported platforms, and optional time-travel behavior, which is sufficient for a fairly simple count tool. An output schema exists, so return-value details need not be described. It stops short of explicitly addressing the sibling `count_view_rows` case, which would have made it fully complete.

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

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

Schema description coverage is 0%, so the description fully compensates. Every parameter is explained with its meaning and format: `workspace` as name/GUID, `item` as warehouse or SQL endpoint name/GUID, `qualified_name` with a `dbo.sales` example, and `as_of` with ISO-8601 semantics and exact query behavior. This is strong value beyond the schema.

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

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

The description clearly states a specific action—return the total row count of a table—and the exact SQL mechanism (`SELECT COUNT_BIG(*)`). It is unambiguous about the resource type (table) but does not explicitly distinguish itself from the sibling `count_view_rows`, so it misses full 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 useful context: it works on both Fabric Data Warehouses and SQL Analytics Endpoints, and it explains when to use or omit the `as_of` parameter for time-travel counts. However, it does not provide explicit guidance on when to use this tool versus alternatives like `count_view_rows` or `read_table`.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the exact SQL mechanism (COUNT_BIG(*)) and the OPTION (FOR TIMESTAMP AS OF ...) behavior when as_of is supplied. This gives the agent meaningful insight beyond the schema.

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

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

The description is compact and well-structured: a one-line purpose, a compatibility note, then a clean Args block. Every sentence contributes to correct invocation, 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?

An output schema exists, so lacking return-value prose is acceptable. The description covers platform compatibility, all parameters, and optional time-travel usage. It does not mention alternatives like count_table_rows, but that is a minor completeness gap given the tool's simplicity.

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

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

Schema description coverage is 0%, so the Args section fully compensates. Every parameter is explained with type guidance and an example for qualified_name. The optional as_of parameter's format and effect are explicitly described.

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 with a specific verb and resource: 'Return the total row count of a view via SELECT COUNT_BIG(*).' The view scoping clearly distinguishes it from count_table_rows and other view 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?

Provides clear context on valid targets: 'Works on both Fabric Data Warehouses and SQL Analytics Endpoints.' It also clarifies when as_of should be used or omitted. It does not explicitly name sibling alternatives, but the scope is sufficiently 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?

With no annotations, the description carries the behavioral disclosure burden, and it does so well: it states this is a pure DDL operation, that no data is read or inserted, and that server-side file access is unreliable in MCP deployments. It also discloses the cluster_by constraint. It falls short of a 5 only because it doesn't mention common behavioral edge cases such as behavior when the table already exists 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?

The description is front-loaded with a one-sentence summary, then provides a compact DDL template, relevant limitations, platform support, and an Arg list. Every sentence adds useful information: the server-side access note explains why inference is excluded, and the constraint about cluster_by prevents misuse. There is no filler or repetition.

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

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

Given the tool's five parameters, no annotations, and an output schema, the description covers the essential behavior, parameter semantics, constraints, supported platforms, and alternatives. An agent has enough context to decide whether to invoke it, construct valid arguments, and know what to expect. The output schema relieves the description of needing to explain return values.

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?

Even though the schema has 0% description coverage, the description fully documents all five parameters, including workspace/item as name or GUID, qualified_name as a dot-separated table name with an example, columns as dicts with name, sql_type, and nullable defaulting to true, and cluster_by as optional with a max of 4 and a validity constraint. This goes well beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Create an empty table from an explicit column spec (DDL only, no data).' It clearly separates this tool from general table creation by emphasizing that it builds a CREATE TABLE statement and reads or inserts no data. It also differentiates from CSV/Parquet-inference workflows by explicitly disclaiming them.

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

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

The description gives explicit when-not guidance: CSV/Parquet inference is not available here, and users are directed to the fabric-dw tables create --from-parquet/--from-csv CLI commands instead. It also states the platform constraint: 'Only supported on Fabric Data Warehouses (not SQL Analytics Endpoints).' This provides clear usage boundaries and a named alternative.

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 present, so the description carries full burden. It discloses that 'body' is executed verbatim as DDL and explains what the body should include. This is critical behavioral context. However, it omits prerequisites (e.g., permissions) or error conditions like if function already exists.

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

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

Description is well-structured: starts with purpose, then context about preview features, a CAUTION, and parameter details. The caution and example add value without excessive verbosity. Slightly dense but appropriate for the complexity.

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

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

Given that an output schema exists, return values are not needed. The description covers what the tool does, behavioral warnings, and parameter semantics. It does not discuss error handling or confirmation, but for a creation tool this is 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 0%, but the description provides detailed explanations for all four parameters in the Args section. It includes examples (e.g., 'qualified_name' with 'dbo.fn_clean_input') and clarifies the content of 'body'. This fully compensates for the missing schema 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?

Description clearly states 'Create a new T-SQL user-defined function' with specific verb and resource. It distinguishes from siblings like 'create_procedure' and 'create_view' by focusing on functions, and adds context about supported environments (Fabric DW, Data Warehouses, SQL Analytics Endpoints).

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 context about preview features and a CAUTION about executing DDL verbatim, but does not explicitly compare to similar creation tools (e.g., when to use create_procedure instead). No exclusion or alternative guidance is given.

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

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

No annotations exist, so the description carries full responsibility. It prominently warns that the body is executed verbatim as DDL and instructs the agent to verify intent before calling—this is a critical behavioral disclosure. It does not mention permissions or what happens if the procedure already exists, but the most significant risk is explicitly surfaced.

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

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

The description is compact and well-structured: a clear purpose statement, a brief platform-support note, a high-visibility caution, and a straightforward parameter list. Every sentence earns its place, and the most important warning is placed before the parameter 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 creation tool with no annotations and an existing output schema, the description covers the core essentials: what it does, where it works, what each parameter means, and the major execution hazard. It omits permission requirements and behavior if the procedure already exists, but these are secondary to the primary safety concern already disclosed.

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

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

The schema provides only type and title for each parameter, so the Args section is essential. It adds concrete meaning by explaining workspace and item as names or GUIDs, providing a dot-separated example for qualified_name ('dbo.usp_load'), and clarifying that body contains the 'AS …' section. This fully compensates for the 0% schema description coverage.

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

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

The description opens with 'Create a new stored procedure,' which names the specific action and resource. It also distinguishes the tool from sibling operations like update_procedure, drop_procedure, and get_procedure by the verb, and clarifies the supported environments (Fabric Data Warehouses and SQL Analytics Endpoints).

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 contextual guidance by stating which platforms support stored procedures, helping the agent determine when the tool is applicable. It does not explicitly contrast with alternatives like update_procedure or list_procedures, but the verb 'create' and the overall context make the intended usage obvious.

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 mentions the creation action and parameter constraints, but lacks disclosure of side effects, required permissions, reversibility, or any behavioral traits beyond the basic operation. The agent has no insight into whether this is a safe, destructive, or constrained operation.

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

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

The description is concise: one sentence for purpose followed by a clear parameter list. Every sentence is necessary and there is no extraneous text. The structure is clean and easy to parse.

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

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

Given that the tool has 4 parameters (2 required) and an output schema (though not displayed), the description provides enough to understand the core operation and parameter inputs. It could be enhanced with more context about the purpose and usage of restore points, but it is largely sufficient for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains required vs optional parameters and adds constraints (max 128 chars for name, max 512 for description). However, it does not clarify the meaning or effect of a restore point, nor how the parameters influence behavior. The description adds some value but not deep semantic context.

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 ('Create a restore point') and the resource ('for a warehouse at the current timestamp'). It is specific and distinguishes from sibling tools like delete_restore_point, get_restore_point, and list_restore_points.

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. There is no mention of prerequisites, typical scenarios, or when not to use it. The description merely states what the tool does without contextual usage advice.

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

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

With no annotations provided, the description carries full burden. It does not disclose potential errors (e.g., schema name conflicts), permission requirements, or side effects beyond stating it creates a schema.

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

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

The description is concise, front-loaded with the main purpose, and includes an Args section. No superfluous 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 presence of an output schema (so return values are covered), the description covers purpose and parameters but lacks detail on error cases, prerequisites, or behavior in edge cases.

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?

Despite 0% schema description coverage, the description adds meaning for all three parameters: workspace and item as name/GUID, name as a valid SQL identifier. This compensates for the lack of schema 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 action (create), the resource (SQL schema), and the target (warehouse or SQL Analytics Endpoint). It effectively distinguishes from sibling tools like delete_schema or list_schemas.

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

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

The description provides context about supported platforms and T-SQL reference, but does not explicitly specify when to use this tool versus alternatives (e.g., create_table, create_view) or when not to use it.

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

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

No annotations provided, so the description carries full burden. It details the SQL operation, predicate requirements, and state parameter behavior. However, it does not disclose permission requirements or consequences of creating duplicate policies.

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?

Well-structured: one-line summary, predicate details, then argument list. Front-loaded with the action. Slightly verbose but every sentence is informative.

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 output schema exists, return values are covered. The description explains the creation process well, but misses edge cases like duplicate policy names and fails to explicitly mention Fabric Data Warehouse context.

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

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

Schema coverage is 0%, so the description fully compensates by explaining each parameter: workspace, item, policy_name, predicates (with required subfields), and state (boolean with default). Adds significant value beyond the schema.

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

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

The description clearly states it creates a row-level security policy using 'CREATE SECURITY POLICY'. It specifies the predicate type limitation (FILTER only) and the required fields. This distinguishes it from siblings like add_security_predicate and set_security_policy_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?

The description explains when to use the tool (to create a new policy) and provides detailed parameter structure. It implicitly differentiates from siblings, but lacks explicit exclusions or when-not-to-use guidance.

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

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

With no annotations, the description must cover behavioral traits. It adds a detail about snapshot_dt timezone handling (naive datetimes as UTC). However, it does not disclose side effects, permission requirements, or immutability of snapshots.

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, front-loads the purpose, and lists parameters efficiently. Every line adds value without redundancy.

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

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

The description covers input parameters adequately but lacks broader context about snapshot lifecycle, prerequisites (e.g., warehouse existence), or post-creation effects. Although output schema exists, more context would improve completeness.

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

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

Schema description coverage is 0%, so the description fully explains parameter meanings. It specifies that workspace/warehouse accept name or GUID, names the optional parameters, and gives format and timezone interpretation for snapshot_dt.

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

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

The description begins with 'Create a new warehouse snapshot', which is a specific verb and resource. It clearly states the action and object, distinguishing it from related tools like create_restore_point.

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

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

The description provides no guidance on when to use this tool versus alternatives such as create_restore_point or list_snapshots. There is no context about prerequisites or expected use cases.

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

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

With no annotations available, the description carries the behavioral transparency burden. It discloses that workspace admin role is required and that the API is beta/preview, which is useful context. It does not describe side effects beyond creating the pool, such as billing impact, reversibility, or validation behavior, but the permission and stability warnings add meaningful transparency.

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

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

The description is well-organized: a one-sentence purpose, a clean Arg list with per-parameter guidance, and a short final line for permissions and API status. Every sentence provides useful information without fluff or redundancy.

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

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

Given seven parameters, no annotations, and zero schema description coverage, the description covers all parameters, defaults, permissions, and beta API risk. The main gap is the absence of usage-routing guidance compared to related pool/warehouse tools, and it does not clarify what a returned result looks like, though an output schema exists. Overall it is nearly complete for a create operation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Every parameter is explained with additional context: workspace accepts name or GUID, name must be unique, max_percent has a 1-100 range, defaults are stated for is_default and optimize_for_reads, and classifier_type/classifier_values include concrete examples. This goes well beyond the schema alone.

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

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

The description opens with a specific verb and object: 'Add a new custom SQL pool to a workspace.' This clearly conveys a create-type operation and the target resource. It does not explicitly differentiate from related sibling tools like create_warehouse, but the phrase 'custom SQL pool' 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?

No explicit guidance is given about when to use this tool versus alternatives such as create_warehouse, list_sql_pools, or update_sql_pool. The description states the admin role requirement and beta API status, which are prerequisites and risk warnings, but does not provide when-to-use or when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the disclosure burden. It explains the Fabric single-column limitation, the SQL Analytics Endpoints read-only restriction, and the fullscan/sample_percent override interaction. It does not discuss permissions, overwrite behavior, or failure modes, but it covers the most material behavioral constraints.

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 front-loaded with the core purpose and key limitations, then organized into a clear Args block. Each parameter receives one concise line. The slight repetition of the SQL Analytics Endpoints restriction is acceptable because it appears at both overview and parameter-specific levels.

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 create operation, the description covers platform support, supported statistic type, parameter semantics, and scan/sample behavior. An output schema exists, so return-value details are not required here. The remaining gaps, such as duplicate-handling and permission requirements, are minor compared to the completeness of the provided context.

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

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

Schema description coverage is 0%, so the description must compensate. It documents all seven parameters, adds practical meaning (workspace name or GUID, warehouse selectivity, qualified table example, sample_percent overrides fullscan), and clarifies how fullscan and sample_percent interact beyond the raw schema.

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

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

The description opens with a specific verb and resource: 'Create a single-column statistic on a table.' It immediately distinguishes itself from sibling statistics tools (list/update/delete/show) by stating the single-column scope and the Data Warehouse target. The purpose is unambiguous.

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

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

The description gives clear when/where context: only Data Warehouses are supported, SQL Analytics Endpoints are read-only and rejected, and only single-column statistics are possible. It does not name alternative tools such as update_statistics or show_statistics, so it falls just short of explicit alternative 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, the description carries the full behavioral disclosure burden and does so thoroughly. It reveals that select_body is executed verbatim as DDL, that the guard is fail-closed and rejects write keywords and semicolons even inside literals, and that column existence is not validated for CTAS. It also explains the exact DDL transformation when cluster_by is supplied.

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

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

The description is long but every section earns its place given the high-risk DDL execution. The key caution is front-loaded early, followed by the guard mechanics and then the parameter details. The warning about write keywords is repeated briefly in Args but that repetition reinforces a safety-critical point rather than wasting space.

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 combines DDL execution, platform restrictions, and a security guard, all of which are disclosed. The description explains the CTAS behavior, the fail-closed validation, the endpoint rejection, the cluster_by DDL shape, and the column validation caveat. Since an output schema exists, return-value details are not required, and nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must compensate for the bare input schema, and it does. Each parameter (workspace, item, qualified_name, select_body, cluster_by) gets a meaningful explanation, including the example for qualified_name, the single-read-only-SELECT constraint, and the cluster_by limit of 4 columns.

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: 'Create a new SQL table via CTAS (CREATE TABLE AS SELECT).' It clearly distinguishes this from siblings like create_empty_table by emphasizing the SELECT-based creation method. The Fabric-specific scope further sharpens 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 explicitly states where the tool is supported (Fabric Data Warehouses) and where it is not (SQL Analytics Endpoints), including the resulting ToolError behavior. It also explains when select_body is acceptable and warns about the guard, giving clear context for use. It does not name a specific alternative tool for non-CTAS table creation, but the exclusion is clear enough.

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

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

With no annotations provided, the description fully discloses key behaviors: select_body is executed as DDL, the guard is always on and fail-closed, and specific keywords are rejected even inside literals. This equips the agent to handle the tool safely.

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

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

The description is well-structured with a purpose line, caution, detailed constraints, and argument descriptions. However, the argument descriptions partially repeat the guard mechanism from the caution, introducing slight redundancy. It remains mostly concise and front-loaded.

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

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

Given the existence of an output schema, return values don't need description. The description covers the creation action, the critical guard, and parameter details. It lacks explicit error handling or prerequisites (e.g., workspace/item must exist), but these are secondary for an AI agent. Overall, 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?

Despite 0% schema description coverage, the description compensates by providing clear explanations for each parameter: workspace (name or GUID), item (warehouse or SQL endpoint), qualified_name (dot-separated view name), and select_body (with constraints). This adds significant meaning beyond the schema.

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

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

The description clearly states 'Create a new SQL view.' as the first line, specifying the verb (create) and resource (SQL view). This distinguishes it from sibling tools like drop_view, update_view, or read_view.

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 explicit warnings about executing select_body verbatim as DDL, specifies that it must be a single read-only SELECT or WITH statement, and details the guard mechanism that rejects write keywords and semicolons. It also gives guidance on rewriting legitimate bodies that contain write keywords.

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 provided, so the description carries the full burden. It only says 'Create a new Warehouse' without disclosing side effects, authorization needs, or error cases. Minimal 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 efficient: front-loaded purpose, then parameter details. The collation list is necessary and well-structured. Slightly verbose but justified.

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?

Covers parameters well but lacks behavioral context (e.g., workspace existence, permissions). Output schema exists but is not referenced; some gaps remain for a creation tool.

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

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

Schema coverage is 0%, but the description explains all four parameters thoroughly, including collation values and defaults. This adds significant meaning beyond the schema.

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

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

The description clearly states 'Create a new Warehouse in a workspace', which is a specific verb and resource. It distinguishes from sibling tools like delete_warehouse, get_warehouse, and list_warehouses.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites or limitations mentioned. For example, it does not say when to use create vs rename or restore.

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 that only user-defined restore points can be deleted, but lacks details on side effects, permissions required, or the response format.

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 concise, front-loading the main purpose, then adding a rule, followed by parameter explanations. No wasted sentences.

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

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

The description is adequate for a delete operation with 3 simple parameters and an output schema present, but it does not mention the return value or error cases. Given the context, it meets the minimum but could be more 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?

With 0% schema description coverage, the description compensates by explaining each parameter: workspace, warehouse, and restore_point_id, including type hints (name or GUID, ID string). This adds meaning beyond the schema.

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

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

The description clearly states 'Delete a user-defined restore point', providing a specific verb and resource. It distinguishes from sibling tools like create_restore_point, get_restore_point, and list_restore_points.

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 includes an exclusion rule: 'System-created restore points cannot be deleted.' This gives clear guidance but does not explicitly mention when to use this tool versus alternatives.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden, and it does so exceptionally. It warns that the operation is destructive and irreversible, that the schema is permanently deleted, that non-empty schemas fail unless cascade is true, and that cascade deletes all tables, views, and data. It also instructs the agent to explicitly confirm with the user before calling with cascade=True.

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

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

The description is well-structured: a clear one-line action, prominent CAUTION warnings for destructive behavior, a supporting note about platform support, and a concise Args section. Every sentence contributes necessary information, and the most safety-critical details are front-loaded.

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

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

Given the tool's destructive nature and the absence of annotations, the description covers all essential context: what is deleted, when the operation fails, what cascade does, and the need for explicit user confirmation. The existence of an output schema reduces the need to describe return values, so no critical behavioral context is missing.

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

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

The input schema provides only names, types, and defaults, so parameter semantics are entirely absent from structured data. The description compensates by explicitly defining workspace, item, name, and cascade, including that workspace and item accept names or GUIDs, item refers to a warehouse or SQL Analytics Endpoint, and cascade controls whether contained tables and views are dropped first.

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

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

The description opens with a specific verb and resource: 'Drop a SQL schema from a warehouse.' It further disambiguates from siblings like drop_view and delete_warehouse by making clear that the target is a schema, and that both Fabric Data Warehouses and SQL Analytics Endpoints are supported.

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 conveys when this tool applies: dropping schemas from supported Fabric data warehouse endpoints. It also explains failure conditions when tables/views exist and the need for cascade, which helps an agent decide whether this tool or a safer alternative is appropriate. It does not explicitly name sibling tools to exclude, but the resource-specific language makes the intended use 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 exist, so the description must disclose behavioral traits. It does not mention irreversibility, required permissions, or effects on dependent objects, leaving the agent without critical safety information.

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 clear sentence with no redundant words. However, it could be expanded slightly to include essential context without becoming verbose.

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

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

The tool has an output schema, but no return details are described. The description does not address the irreversible nature of deletion or the need for confirmation, making it incomplete for a destructive operation.

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

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

Schema description coverage is 0%. The description only restates the parameter names (workspace, snapshot) without adding any meaning 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?

The description 'Delete a warehouse snapshot' clearly states the action (delete) and the resource (warehouse snapshot). It effectively distinguishes from siblings like create_snapshot and rename_snapshot.

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 (e.g., restore_warehouse_in_place, roll_snapshot_timestamp). No prerequisites or context for safe usage 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?

With no annotations provided, the description must carry the behavioral burden. It does disclose the admin role requirement and the beta/preview API status, which is useful, but it does not mention whether deletion is permanent, whether dependent objects are affected, or any other side effects beyond the implied destructive action.

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: a one-sentence summary, a short Args list, and then relevant requirement notes. Every sentence adds information without waste.

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 covers the core requirements: what is deleted, what parameters to provide, admin role, and API status. An output schema exists, so return-value documentation is not needed. It could add more about side effects, but the essentials are present.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that workspace accepts a name or GUID and that pool_name is the pool to delete. This adds some meaning, though the parameter meanings are largely evident from their names.

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

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

The description clearly states the action ('Delete an SQL pool from a workspace') with a specific verb and resource. It is immediately distinguishable from sibling tools like delete_warehouse, and the resource type is unambiguous.

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

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

No guidance is given about when to choose this tool versus alternatives such as delete_warehouse, or any conditions under which deletion is appropriate. The admin role requirement is a prerequisite, not a usage guideline.

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

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

With no annotations, the description carries full burden. It prominently warns 'This is a destructive, irreversible operation' and adds platform constraints (read-only SQL Analytics Endpoints) and the rejection case. This discloses the most important behavioral traits. It does not cover permissions, error behavior, or dependency conflicts, but for a destructive drop operation the core warning is present.

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

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

The description is compact and well-organized: a one-line purpose, a two-line caution/constraint block, and a clean Args list. No filler; every sentence adds operational information. The destructive warning is front-loaded before the args.

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 four required parameters, zero schema descriptions, no annotations, and an output schema present, this description covers what the tool does, where it works, what is rejected, and what each argument means. The omission of return-value details is acceptable because an output schema exists. The warning and scope fully equip an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate and does. Each of the four required parameters gets a meaningful explanation: workspace (name/GUID), item (warehouse name/GUID, with SQL Analytics Endpoints rejected), qualified_table (with an example), and stat_name. This adds real semantic value the schema lacks.

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

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

The description opens with 'Drop a statistic via DROP STATISTICS', naming a specific verb ('Drop') and resource ('a statistic'), and equates it to the SQL command. This distinguishes it clearly from sibling tools like create_statistics, update_statistics, and list/show_statistics.

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

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

It explicitly states the tool is 'Only supported on Data Warehouses (SQL Analytics Endpoints are read-only)' and later repeats that SQL Analytics Endpoints are rejected for the 'item' parameter. This gives clear context and a hard exclusion, though it does not explicitly name alternatives or say 'use this when you need to permanently remove a statistic' beyond the obvious purpose.

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 clearly warns that the operation is destructive, irreversible, permanently deletes the table and all its data, and instructs the agent to confirm with the user. It also discloses the endpoint rejection behavior, which is valuable beyond basic intent.

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-loaded with a one-sentence purpose, then a short constraint paragraph, a caution warning, and a compact Args list. No filler or redundancy; every sentence earns its place.

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

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

For a destructive tool with no annotations and no schema descriptions, it covers what the tool does, where it works, what fails, the safety warning, and every parameter. The output schema exists to handle return shape, so nothing essential is missing.

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

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

Schema description coverage is 0%, but the description documents all three parameters with real meaning: workspace name/GUID, warehouse name/GUID with endpoint rejection, and qualified_name format with the example 'dbo.sales'. This adds substantial value beyond the bare schema.

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

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

Opens with 'Drop a SQL table.' — a specific verb and resource that immediately distinguishes it from sibling delete/drop tools like delete_warehouse, drop_view, and drop_procedure. The title and field names reinforce the intent.

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

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

States an explicit constraint: only supported on Fabric Data Warehouses, not SQL Analytics Endpoints, and even discloses that the service rejects endpoints with a ToolError. It does not explicitly name alternative tools for non-table objects, but the resource scope plus the exclusion is enough for routing.

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

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

No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only states 'Delete' with no mention of irreversibility, permissions, side effects on dependent objects, or whether it requires the warehouse to be idle. This is insufficient for safe use.

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

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

The description is extremely short (5 words), but this is not efficient conciseness; it is under-specification. It fails to earn its place by omitting critical information that would be expected in a minimal viable description.

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 an output schema, but the description does not hint at return values. It lacks details on prerequisites, side effects, or error conditions. For a delete operation with two required parameters, the description is severely incomplete.

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

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

Schema description coverage is 0%, and the description provides no explanation of the 'workspace' and 'warehouse' parameters. Although the parameter names are self-explanatory, the description adds no semantic value beyond what the schema already implies.

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 the verb 'Delete' and the resource 'Warehouse', making the basic purpose clear. However, it is a tautology of the tool name and lacks any scope or distinguishing details from sibling tools like restore_warehouse_in_place or rename_warehouse.

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

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

No guidance on when to use this tool versus alternatives. It does not specify prerequisites (e.g., warehouse must exist), when not to use it, or any order of operations relative to sibling tools.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool executes a SQL DENY command, lists preconditions (blocked by readonly), and provides constraints on parameters (e.g., columns only for OBJECT scope with specific permissions, empty list raises error). It could be improved by noting return value or idempotency.

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

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

The description is well-structured with a brief intro followed by a parameter list. The parameter descriptions are concise but comprehensive. Minor repetition could be trimmed, but overall it is efficient and front-loaded.

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

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

Given 8 parameters, 4 required, and no schema descriptions, the description covers all necessary information for usage, including constraints and examples. It does not describe the output schema, but that exists separately. Overall, it is complete enough for an AI agent to invoke correctly.

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

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

Schema description coverage is 0%, so the description must add meaning. It does so thoroughly, explaining each parameter's purpose, default values, required conditions, and constraints (e.g., schema required when scope is SCHEMA, columns limited to certain permissions). This far exceeds what the schema alone provides.

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

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

The description clearly states the action ('Deny permissions') and the target ('securable to a principal'), and provides the SQL equivalent. This is a specific verb-resource pair that distinguishes it from siblings like grant_permission and revoke_permission.

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 mentions that the tool is blocked by FABRIC_MCP_READONLY and does not require FABRIC_MCP_ALLOW_DESTRUCTIVE, providing some behavioral context. However, it does not explicitly guide when to use deny vs. grant/revoke, nor does it mention prerequisites like having appropriate permissions to execute the denial.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly details the eventual-consistency mechanism, the risk of silent reversion, and the recommended spacing of writes. This is excellent 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 concise (five sentences) with a clear structure: purpose statement, caution block, and parameter list. Every sentence adds value—no fluff or redundancy.

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

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

Although an output schema exists (not shown), the description covers the essential action and critical behavioral nuance. It does not mention what the tool returns or failure cases, but the presence of an output schema mitigates the need for that in the description. The tool's context among siblings (e.g., enable_audit) is not explicitly addressed, but the core purpose is complete.

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

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

Schema coverage is 0%, so the description must compensate. It adds value by clarifying that both 'workspace' and 'warehouse' accept names or GUIDs, which is not evident from the schema (which only provides titles). This is helpful but could be more detailed (e.g., no default values or examples).

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

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

The description clearly states the specific action 'Disable SQL auditing' on a defined resource ('a warehouse or SQL analytics endpoint'). It uses a strong verb-noun combination that distinguishes it from sibling tools like enable_audit and get_audit_settings.

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 warns about eventual consistency and silent reversion, providing a crucial 'when to use with caution' guideline. However, it lacks explicit direction on when to prefer this tool over alternatives (e.g., enable_audit) or when not to use it.

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

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

With no annotations, the description carries the behavioral burden and does this well by disclosing that configuration is preserved, re-enabling restores it, admin role is required, and the API is beta/preview. It doesn't describe effects on currently running SQL pools or idempotency, but the key behavioral traits are communicated.

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

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

The description is compact and front-loaded with the core action. Each line earns its place: preserving configuration, re-enabling via the sibling tool, admin requirement, and beta API warning. There is 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 low-complexity tool with one required parameter and an output schema present, the description covers prerequisites, reversibility, and API stability. The main gap is the missing workspace identifier format, which prevents fully confident invocation without elsewhere.

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

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

Schema description coverage is 0%, and the only parameter 'workspace' is a bare string. The description repeats the word 'workspace' but does not clarify whether it expects a workspace ID, name, path, or how to format it. Given the low coverage, the description needed to compensate with parameter semantics and did not.

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 ('Disable custom SQL Pools for a workspace') with a precise resource and scope. It also differentiates itself from enable_sql_pools and implies a non-destructive distinction from delete_sql_pool by noting configuration is preserved.

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

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

The description provides clear context: it is an admin-only, reversible operation, and it explicitly names enable_sql_pools as the re-enabling counterpart. It does not explicitly say 'use this instead of delete_sql_pool' or when not to use it, but the context is strong enough for routing.

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

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

No annotations are provided, so the description carries full burden. It clearly labels the operation as 'permanently destructive' and warns that unmasked values become visible. It also notes the environment variable requirement. This is good transparency for a destructive tool.

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

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

The description is concise with a clear purpose sentence, followed by the SQL invocation, destructive warning, requirement, and parameter list. Every sentence adds value without redundancy. Front-loaded with the most important info.

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

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

Given the complexity (5 required params, destructive operation, no annotations), the description covers the essential behavior and prerequisites. It does not explain return values, but an output schema exists. Missing details like error conditions are acceptable for this level of detail.

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

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

Schema description coverage is 0%, so the description must compensate. It lists each parameter with brief clarification (e.g., 'Workspace name or GUID', 'Warehouse or SQL endpoint name or GUID'). This adds minor meaning beyond the schema titles, but does not explain constraints or formats.

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

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

The description explicitly states 'Remove a dynamic data mask from a column,' which is a specific verb and resource. It clearly distinguishes from sibling tools like set_column_mask (sets a mask) and list_masked_columns (lists masks).

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 mentions the underlying SQL command and requires FABRIC_MCP_ALLOW_DESTRUCTIVE=1, but does not explicitly state when to use this tool versus alternatives like set_column_mask. Usage context is implied but not directly 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the if_exists no-op behavior, the exact return payload {'dropped': false} for missing functions, and the default of false. It does not discuss irreversibility or permission requirements, but 'drop' inherently signals destruction and the added behavioral specifics are valuable.

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

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

The description is compact and well-organized. The action statement comes first, followed by a short platform note and a clean Args list. Every sentence adds necessary information without repetition 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?

The description covers the tool's purpose, supported environments, all parameter semantics, and the key edge case (if_exists). Since an output schema exists, the success return shape does not need to be spelled out in the description, though a brief note about the non-if_exists success response would have been slightly more complete.

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

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

Schema description coverage is 0%, but the description fully documents all four parameters: workspace is a name or GUID, item is a Warehouse or SQL Analytics Endpoint, qualified_name is a dot-separated qualified function name with a concrete example, and if_exists is explained with its behavior and default. This goes well beyond the bare schema titles.

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

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

The description opens with a specific verb and resource: 'Drop a T-SQL user-defined function.' This cleanly distinguishes the tool from sibling drop tools like drop_view and drop_procedure based on the object type, and it adds platform scope by noting support for both Data Warehouses and SQL Analytics Endpoints.

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 for when the tool applies: it is for T-SQL user-defined functions and works on both Data Warehouses and SQL Analytics Endpoints. It does not explicitly name alternatives or exclusions, but the resource type and platform note make the intended use clear enough.

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

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

With no annotations, the description must carry the burden of disclosing destructive behavior. It does state the object being dropped and the supported platforms, but it doesn't mention permanence, permission requirements, or whether the drop cascades to dependencies. This is not misleading but leaves some behavioral depth unstated.

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

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

The description is compact and front-loaded: the core action appears in the first sentence, followed by platform context and then a clean Args list. Every sentence 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?

For a three-parameter drop tool, the description covers the action, target platforms, and parameter semantics. The presence of an output schema reduces the need to explain return values. It could add an explicit irreversibility warning, but the overall definition is sufficiently complete for an agent to call 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 0%, so the Args section is essential. It explains each parameter: workspace as name or GUID, item as warehouse or SQL endpoint, and qualified_name as a dot-separated qualified procedure name with a concrete example ('dbo.usp_load'). This fully compensates for the bare schema.

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

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

The description opens with a specific verb and resource ('Drop a stored procedure'), making the tool's action unambiguous and distinguishing it from sibling drop tools like drop_view and drop_function. The supported environments add further precision about what kinds of items can be targeted.

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 statement that stored procedures are supported on both Fabric Data Warehouses and SQL Analytics Endpoints gives clear context about when this tool can be applied. It doesn't explicitly exclude alternatives, but the resource type is clear enough that an agent can select it for dropping procedures.

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 provided, so description carries full burden. It discloses permanent destruction of policy and predicates, and the environment variable prerequisite. This is sufficient 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?

Highly concise: two main sentences plus a bullet-pointed args list. Front-loaded with the action, no superfluous text.

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 low complexity and presence of output schema (context signal), the description covers all necessary aspects: purpose, destructive nature, prerequisite, parameter guidance. Minor omission: no mention of return value, but not critical for drop operations.

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

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

Schema coverage is 0%, but description adds meaning by explaining 'policy_name' format (qualified name) and context for workspace and item. This compensates for lack of schema 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?

Description clearly states 'Drop a row-level security policy' and references 'Executes DROP SECURITY POLICY', making the verb and resource explicit. It distinguishes itself from siblings like create_security_policy and set_security_policy_state.

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

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

Explicitly warns it is a permanently destructive operation and requires FABRIC_MCP_ALLOW_DESTRUCTIVE=1, guiding when to use. Does not explicitly state when not to use, but the destructive nature implies alternatives (e.g., disabling).

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

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

Without annotations, the description carries full burden. It discloses the underlying SQL command and notes that Fabric Data Warehouse supports only FILTER predicates, referencing a GitHub issue. However, it omits permissions, side effects, or reversibility, leaving gaps in behavioral understanding.

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: a clear action sentence, a technical detail paragraph, and an Args list. It is well-structured and free of unnecessary content, though the Args list could be integrated into the prose.

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

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

Given no annotations, the description covers the core action and SQL details. It references a GitHub issue and explains the lack of predicate-type parameter. However, it does not cover prerequisites (e.g., policy existence), error scenarios, or output behavior, 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 0%, so description must compensate. It lists all five parameters in an Args block and adds format info for policy_name ('"schema.name" or "name"'). Other parameters have no added semantics beyond their names, which is acceptable but not fully compensating.

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: 'Drop the FILTER predicate from an existing row-level security policy.' It distinguishes from related tools like add_security_predicate and drop_security_policy by specifying the exact operation on a predicate.

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 on when to use this tool versus alternatives (e.g., drop_security_policy or set_security_policy_state). The description mentions technical constraints but does not provide usage scenarios or prerequisites.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It merely states 'Drop' without mentioning irreversibility, permission requirements, or side effects (e.g., cascading drops). For a destructive operation, this is insufficient.

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: a single line for purpose followed by parameter details. Every sentence earns its place with no redundancy or unnecessary text.

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

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

Given the simple nature of the tool and the presence of an output schema, the description covers basic purpose and parameters. However, it lacks usage context or clarification of behavior (e.g., error cases, prerequisites), making it 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?

Since the input schema has no descriptions (0% coverage), the description compensates by explaining each parameter: workspace, item, and qualified_name with an example format. This adds meaningful guidance beyond the schema structure.

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

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

The description explicitly states 'Drop a SQL view,' which is a clear verb+resource combination. This distinguishes it from sibling tools like create_view, read_view, or rename_view.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., drop_table, drop_function) nor any prerequisites or context. It only states the action without usage context.

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

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

With no annotations, the description carries full burden and reveals a critical behavioral trait: the pre-flight GET is eventually consistent and may silently revert recent changes. This is valuable transparency. However, it does not mention idempotency or behavior when audit is already 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?

The description is concise with a clear purpose statement, a caution note, and parameter explanations. It is well-structured and front-loaded. The caution is somewhat lengthy but necessary for transparency.

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 there is an output schema (not provided), the description does not need to cover return values. However, it omits prerequisites like required permissions or warehouse existence. The caution about eventual consistency is helpful but the description lacks information about error states or idempotency.

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

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

The input schema has no descriptions (0% coverage), but the description includes an Args block that explains each parameter beyond the schema's property titles. It clarifies the meaning of workspace, warehouse, and retention_days with range and default, adding significant semantics.

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

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

The description clearly states the tool enables SQL auditing on a warehouse or SQL analytics endpoint. This is specific and distinguishes it from sibling tools like 'disable_audit' and 'set_audit_retention'.

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 caution about spacing writes due to eventual consistency, but does not explicitly state when to use this tool versus alternatives such as 'set_audit_retention' or 'add_audit_group'. The caution implies some usage advice but not comprehensive guidance.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds some useful context: admin role requirement, beta API warning, and the behavioral guarantee that pool definitions are not modified. However, it does not disclose side effects, idempotency, reversibility, or what happens if SQL pools are already 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?

The description is concise at three sentences, each earning its place: the core function, the access requirement, and the beta warning. It is front-loaded and contains no filler. Minor improvement could be made by more explicit off-ramps to siblings.

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 a simple single-parameter schema and an output schema to explain return values, so complexity is low. Still, the description omits whether this is a one-time enablement, whether it affects existing SQL pools, or how to check current status (even though get_sql_pools_status is a sibling). It is minimally adequate but leaves operational context unclear.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'workspace' parameter. It only repeats 'for a workspace' without specifying whether the value is a workspace ID, name, or URL, and without any additional format or usage guidance. The single parameter remains under-specified.

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: 'Enable custom SQL Pools for a workspace.' The clarifying phrase 'without modifying pool definitions' sets it apart from create/update/delete SQL pool siblings, so an agent can distinguish it from those tools. It does not explicitly mention the corresponding disable_sql_pools sibling, but the action is clearly scoped.

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 prerequisites: workspace admin role and beta/preview API status. It does not explicitly state when to choose this over alternatives, though 'without modifying pool definitions' implies its scope relative to pool definition mutation. No exclusions or alternative routing are given.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure, and it does so thoroughly. It warns that DDL and DML are permitted, explains multi-statement batch result selection, describes how datetime, Decimal, and bytes values are serialized, and documents truncation behavior via max_rows + 1.

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

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

The description is long but every major block earns its place: purpose, usage guidance, safety warning, batch semantics, serialization details, performance advice, and parameter meanings. It is front-loaded with the most decision-relevant information and uses clear paragraph separation.

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-complexity, potentially destructive tool with no annotations, the description is exceptionally complete. It covers safety, alternative routing, batch semantics, return value structure, type serialization, and performance considerations, leaving little for an agent to guess.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter is explained beyond its raw schema definition: workspace and item accept names or GUIDs, query is a SQL statement or batch, and max_rows has bounds, default, and truncation implications.

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

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

The description opens with a specific verb and resource: 'Execute an arbitrary SQL statement or batch against a warehouse or SQL Analytics Endpoint.' It clearly distinguishes this generic SQL tool from the many dedicated sibling tools by emphasizing arbitrariness and raw SQL execution.

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

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

The description explicitly lists dedicated alternatives (read_table, read_view, count_table_rows, etc.) and states to prefer them for common operations. It also gives direct when-to-use guidance: use execute_sql only when the user explicitly requests data modification, and default to SELECT for read-only investigation.

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

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

With no annotations, the description carries the full burden and discloses the two most important behaviors: the server cannot write to the caller's filesystem, and ServicePrincipal mode emits env_var placeholders with no literal secrets. It also documents the conditional behavior of with_sources and the exact return format, though it never explicitly states the operation is read-only and says nothing about error behavior for invalid workspace/item input.

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

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

The description is long but proportionally justified: every block — purpose, filesystem limitation, auth note, Args, Returns — adds information the schema and annotations fail to provide. It is front-loaded with purpose and the key behavioral caveat before the parameter reference, 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 9-parameter tool with zero annotations, zero schema descriptions, and a complex multi-file return contract, the description is nearly exhaustive: all parameters, all 5 return keys, and the critical auth and filesystem caveats are covered. Missing only error behavior for invalid workspace/item and an explicit side-effect profile, which are minor relative to what is provided.

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

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

Schema description coverage is 0%, so the description must compensate — and it documents all 9 parameters with plain-language meaning and default resolution (e.g., project_name defaults to 'sanitized warehouse name', authentication defaults to the server's auth mode, with_sources triggers actual schema/table introspection). Every parameter receives context beyond its title, which is exceptional at this coverage level.

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: 'Generate dbt-fabric project file contents for a Fabric Data Warehouse.' The output contract (multi-file text contents) is uniquely identifiable, and no sibling tool performs file-content generation, so it is immediately distinguishable from the ~120 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?

Provides clear operational context: the caller must write returned strings because the MCP server cannot write to the local filesystem, and the authentication note explains supported modes (auto/CLI/ServicePrincipal) and defaulting behavior. Does not explicitly state when-not-to-use or name alternatives, but no sibling tool competes for this generation task, so exclusion guidance is unnecessary.

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 correctly implies a read-only operation ('Fetch'), but does not explicitly state non-destructiveness or any required permissions. Adequate but could be more explicit.

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?

Very concise: one-line purpose followed by a clear parameter list. No wasted words, front-loaded with key 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?

Sufficient for a simple retrieval tool with output schema available. Covers parameters adequately, but missing usage guidelines and behavioral disclaimers prevent a higher score.

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?

Adds meaningful detail beyond input schema by specifying that workspace and warehouse accept names or GUIDs. Schema has 0% coverage, so description compensates well, though could include format hints.

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

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

Clearly states it fetches current SQL audit settings for a warehouse or SQL analytics endpoint. Differentiates from sibling tools like enable_audit, disable_audit, and set_audit_action_groups by focusing on retrieval.

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

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

No guidance on when to use this tool versus alternatives like enable_audit or set_audit_action_groups. Lacks context for appropriate usage or prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the platform limitation, the error condition on SQL Analytics Endpoints, and the empty-list result when no clustering columns exist, which gives the agent useful expectations beyond the raw 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 compact and front-loaded, leading with the primary purpose and ordering behavior, then adding constraints and parameters. Every sentence contributes useful information 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?

The description fully covers what the tool does, its supported platforms, failure behavior, edge case, and all parameter formats. Since an output schema exists, the return structure does not need to be explained 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 0%, but the description compensates fully by documenting all three parameters: workspace name or GUID, warehouse name or GUID, and a dot-separated qualified table name with an example. This adds real meaning that the bare input schema lacks.

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: 'Return the data-clustering columns of a table, ordered by clustering ordinal.' It clearly differs from siblings like get_table_columns or set_cluster_columns by focusing on clustering-column metadata and mentioning ordering behavior.

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 usage constraints: it is supported only on Fabric Data Warehouses and raises a ToolError on SQL Analytics Endpoints. It does not explicitly name alternatives, but this exclusion is strong enough to guide selection in most cases.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains that it returns the function definition from sys.sql_modules and parameter list from sys.parameters, and specifies supported function types and platforms. Missing details on permissions or error handling, but sufficient for a read-only tool.

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

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

The description is highly concise with clear section headings (Args:) and front-loaded key details. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity and presence of an output schema, the description covers purpose, parameters, supported types, and platforms adequately. Minor gap: does not mention error cases (e.g., function not found), but overall complete for agent 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 schema description coverage is 0%, so the description must compensate. It defines 'qualified_name' as a dot-separated function name with an example, but does not explain 'workspace' and 'item' beyond their types. Thus, it adds some value but not comprehensive parameter semantics.

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

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

The description clearly states it fetches the full definition of a T-SQL user-defined function, including function definition and parameter list. It specifies supported types (scalar UDFs, inline TVFs) and platforms (Data Warehouses, SQL Analytics Endpoints), distinguishing it from sibling tools like get_view or get_procedure.

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 lacks explicit guidance on when to use this tool versus alternatives like list_functions. It implies usage for detailed function definitions but does not state when not to use or provide 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 behavior. 'Fetch' implies a read-only operation, which is adequate. It does not detail side effects, permissions, or error handling, but the presence of an output schema covers return values. The description meets the minimum but lacks depth for a no-annotation setting.

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 short and to the point: one sentence for the action, one for support context, then a concise list of parameters. It is front-loaded with the purpose and contains no unnecessary 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 tool's simplicity (fetching a procedure definition) and the presence of an output schema, the description sufficiently covers the purpose, supported environments, and required arguments. An agent has enough information to use 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 coverage is 0%, so parameters are undocumented in the schema. The description adds meaning by naming and briefly explaining each parameter: workspace (name or GUID), item (warehouse or SQL endpoint), and qualified_name (dot-separated, with example). This compensates for the schema gap, though more detail on GUIDs could be added.

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

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

The description starts with 'Fetch the full definition of a stored procedure (schema.proc)', clearly stating the specific verb (fetch) and resource (stored procedure definition). It distinguishes from siblings like list_procedures and create_procedure by specifying 'full definition' and mentioning the qualified name format.

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

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

The description states that stored procedures are supported on both Fabric Data Warehouses and SQL Analytics Endpoints, providing context for when to use it. However, it does not explicitly contrast with alternatives like list_procedures for names or create_procedure for creation.

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

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

With no annotations provided, the description fully discloses behavior: no query execution, no side effects, format options, and artifact formats are CLI-only. It contradicts no annotations.

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

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

The description is well-structured with clear sections, bullet points, and a format table. While somewhat lengthy, each section adds value. It is front-loaded with the most critical info.

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

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

Given the presence of many sibling tools and an output schema, the description is complete. It covers purpose, usage guidelines, parameters, format options, and return types, leaving no gaps for an AI agent.

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?

Despite 0% schema description coverage, the description provides a detailed Args section explaining each parameter, including format enum options with defaults. This adds substantial meaning beyond the raw schema.

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

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

The description clearly states it captures the estimated execution plan as SHOWPLAN_XML without executing the query. It distinguishes itself from sibling tools like execute_sql that actually run queries.

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

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

It explicitly states when to use this tool (to get an execution plan without execution) and when not to (requires actual execution). It also mentions safety under FABRIC_MCP_READONLY=1 and that DDL/DML is safe because no data is modified.

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 does disclose the source table, the lookup key, and the returned content (query text and execution metrics), but it does not clarify read-only safety, permissions, or error/not-found behavior.

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

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

The description is well-structured with a clear opening sentence and a parameter list. There is minor redundancy between 'completed query' and 'after the query completes,' but the text remains compact and easily 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 simple lookup tool with an output schema, the description is mostly complete: it identifies the source, the lookup key, the parameters, and the output type. It could be stronger by noting how to obtain distributed_statement_id or how this relates to request history listing tools.

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

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

Schema description coverage is 0%, so the parameter documentation in the description is essential and effective. Each parameter gets a clear semantic definition, including accepted forms like 'name or GUID' for workspace and item, and 'GUID' for dist_statement_id.

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

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

The description states a specific action ('Look up a completed query') and a precise resource (queryinsights.exec_requests_history), and explains that it returns full query text and execution metrics. This distinguishes it clearly from list-oriented siblings like list_request_history and running-query 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 when to use the tool: after a query has completed and when a distributed_statement_id is available. However, it does not explicitly mention alternatives or state when not to use it.

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

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

No annotations exist, so the description carries the burden. It clearly indicates a read operation ('Return') and provides an example for the restore_point_id parameter. No conflicting behavior is stated, and the tool is straightforward.

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: one sentence for the purpose followed by three lines listing parameters with minimal explanation. No redundant information, and the main action is front-loaded.

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

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

Given the tool's simplicity (3 required parameters, output schema present), the description covers the essential behavior and parameters. It does not mention error handling or prerequisites, but for a straightforward get operation, it is 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 coverage is 0%, so the description must compensate. It lists all three parameters and notes that workspace and warehouse are 'name or GUID', and gives an example for restore_point_id. This adds basic meaning but lacks detailed format or constraints.

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 'Return a single restore point by ID' uses a specific verb and resource, clearly distinguishing it from sibling tools like list_restore_points (multiple) and create/delete/update (different operations).

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

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

No guidance is provided on when to use this tool versus alternatives such as list_restore_points or get_warehouse. The description simply states what it does without context on appropriate use.

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 provided, so description must disclose behavioral traits. It only states 'Return details' without mentioning error behavior, permissions, idempotency, or rate limits. This is insufficient for a safe agent invocation.

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?

Single sentence, 10 words, directly states purpose with no redundancy. Front-loaded and efficient.

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

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

Tool has an output schema, so return details need not be described. However, the description misses constraints (e.g., workspace requirement, what if endpoint not found). Still, for a simple retrieval tool, it is mostly complete.

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

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

Schema coverage is 0%, but description adds minimal semantics by specifying endpoint identifier as 'name or GUID'. However, both parameters (workspace and endpoint) lack further explanation of format or constraints.

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

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

Description clearly states the action ('Return'), resource ('details for a single SQL analytics endpoint'), and identifier type ('name or GUID'), distinguishing it from sibling tools like list_sql_endpoints (listing all) and get_sql_endpoint_permissions (permissions).

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 use when needing details for one endpoint, but no explicit when-not or alternatives (e.g., vs list_sql_endpoints). However, the clear purpose and sibling list provide enough context for selection.

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

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

No annotations are present, so the description carries full behavioral disclosure burden. It adds two genuinely useful facts beyond the name: the workspace admin role requirement and the beta/preview API warning. However, it discloses nothing about the return shape, error behavior, or lack of side effects, which leaves gaps for a no-annotation tool.

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

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

The description is well structured: purpose sentence first, then compact arg docs, then two one-line caveats. Only minor waste is 'pool_name: The pool name', which echoes the schema title, but overall the text is tight and front-loaded.

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

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

For a simple two-parameter get-by-name tool, the description covers the essentials: what it does, both parameters, the admin-role precondition, and API stability. The two notable omissions are the explicit return-value format (no output schema exists to cover it) and differentiation from get_sql_pools_status, but the core invocation needs are met.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for workspace ('Workspace name or GUID'), which is valuable beyond the schema's bare string type. But 'pool_name: The pool name' merely restates the property title and adds no meaning about format, uniqueness, or qualification.

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

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

The description opens with a specific verb-resource pair: 'Return details for a single SQL pool by name.' This clearly identifies a singular-get operation and distinguishes it from siblings like list_sql_pools (plural listing) and get_sql_pools_status (status-specific). 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?

The description provides useful context (requires workspace admin role, targets a beta/preview API) but never explicitly states when to use this tool versus alternatives such as list_sql_pools or get_sql_pools_status. Usage is implied rather than stated; no exclusions or alternative routing are given.

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

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

With no annotations provided, the description carries the full burden. It discloses the workspace admin role requirement and notes that the tool targets a beta/preview API endpoint that may change. This is valuable behavioral context beyond the schema.

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

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

The description is concise and well-structured. The main purpose is front-loaded, followed by alternative tools, and then important caveats. Every sentence adds useful information 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?

For a simple status-check tool with one parameter and an output schema, the description covers the core purpose, the exact return field, admin requirements, API stability, and clear sibling tool differentiation. Nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must compensate for the single `workspace` parameter. It says 'for a workspace' but does not clarify whether the value should be a workspace ID, name, URL, or provide any format or constraints. The parameter meaning is largely inferred from its name.

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: 'Return whether custom SQL Pools are enabled for a workspace.' It also explicitly names what it returns (the `customSQLPoolsEnabled` switch), distinguishing it from related pool-list and pool-detail tools.

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

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

The description provides explicit guidance for when to use this tool vs alternatives: it returns only the workspace-level switch, while `list_sql_pools` is for the pool list and `get_sql_pool` is for a single pool's details. This is direct and unambiguous.

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