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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds behavioral context about the content returned (caller and error message) and the scoping options, which goes beyond the structured fields. It does not mention pagination or error handling, but that is minor given the 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?

Two sentences with no redundancy. The purpose is front-loaded in the first sentence, and the second adds actionable usage guidance. Every clause earns its place, making it an exemplar of concision.

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

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

For a read-only log-listing tool, the description covers the essential aspects: what is returned, how to scope, and filtering. The lack of an output schema is partially mitigated by mentioning the caller and error message. It does not detail the event structure or pagination behavior, but these are either inferable or covered by parameters.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description enhances meaning for 'scope' by explaining the three scoping levels, and for 'onlyFailures' by stating its purpose. This adds value over the schema, though it does not elaborate on 'hours' or 'limit' beyond their defaults.

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

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

The description states a specific verb ('Lists') and resource ('control-plane operations from the Azure activity log'), and gives concrete examples (deployments, restarts, scaling, etc.) that make its purpose unmistakable. It also differentiates itself from sibling log tools by explicitly scoping to control-plane operations, which is distinct from data-plane logs.

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

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

The description provides clear usage context: how to scope (resource, resource group, subscription) and how to filter (onlyFailures). However, it does not explicitly name alternatives or state when not to use this tool, leaving the differentiation to implication rather than direct 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?

Annotations already establish readOnly/openWorld/idempotent behavior. The description adds valuable behavioral context by specifying what aspects are summarized and by disclosing that it reports reachability for azure_aks_workloads and azure_aks_pod_logs. This goes well beyond the annotations and helps the agent understand what to expect.

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

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

Two sentences, both of which earn their place. The first is dense but organized and front-loaded with the primary purpose; the second adds a unique capability that is important for tool selection among 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?

For a read-only overview tool with one well-documented parameter and strong annotations, the description is complete. It lists the categories of information returned and includes the cross-tool reachability detail, so an agent has enough context to select and 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?

The schema has 100% coverage for the single clusterId parameter, including its meaning as a Resource ID. The description adds no additional parameter-level detail beyond mentioning that the summary comes from Azure Resource Manager, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool summarizes an AKS cluster and enumerates the exact information it covers: power and provisioning state, Kubernetes version and upgrades, node pools, networking, identity, and add-ons. This distinguishes it from generic get_resource tools and from sibling tools like azure_aks_workloads and azure_aks_pod_logs.

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 makes the tool's scope evident: use it for a high-level overview of an AKS cluster and to check whether related workload/log tools can reach that cluster. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough given the sibling tool list.

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

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

Annotations already mark the operation read-only and idempotent; the description adds useful behavioral context by specifying the Kubernetes API route, read-only semantics, and how 'previous' exposes logs from crashed container instances. This goes beyond the structured annotations without contradicting them.

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

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

Three sentences with no fluff: the main purpose is front-loaded, the special 'previous' behavior is explained, and a useful sibling lookup hint is included. Every sentence contributes operational guidance.

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

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

For a 7-parameter tool, the schema covers parameter details and annotations cover safety/idempotency. The description adds the missing operational context: how to get crashed-instance logs and where to find pod names, making the tool fully usable without further lookups.

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

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

Schema description coverage is 100%, so the schema fully documents parameters like pod, namespace, clusterId, container, tailLines, and sinceMinutes. The description adds value by explaining the purpose of 'previous' and directing users to find pod names, but most parameter semantics remain in the schema.

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

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

The description clearly states the verb 'Reads' and the specific resource: last log lines of a pod container in an AKS cluster via the Kubernetes API. It distinguishes this from log analytics or container app logs by scoping to AKS pod containers.

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

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

The description gives clear context for when to use the tool, including the CrashLoopBackOff scenario with 'previous' and a pointer to azure_aks_workloads for finding pod names. It does not explicitly contrast it with other log-query siblings, but the AKS pod-scoped use case 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?

Annotations already mark it read-only, non-destructive, and idempotent; the description adds that authentication uses the caller's Entra ID account and that the data is live from the Kubernetes API. It also defines what 'problems' filters to, providing behavioral detail beyond the structured annotations.

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

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

Three sentences front-load the core read-only workload purpose, explain the default behavior, enumerate views, and state the optional namespace. No filler or repetition of schema details.

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

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

For a read-only listing tool with a small parameter set, the description covers purpose, auth, views, and namespace scoping. There is no output schema, but the absence of a return-format description is a minor gap because the semantics of each view are already explained.

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 complete, so the baseline is a 3. The description adds real value by explaining the semantic difference between the 'problems' view and the 'everything' views, and by noting that namespace is optional; 'limit' remains schema-described but not enriched.

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: 'Reads live workload state from an AKS cluster's Kubernetes API'. It enumerates distinct views and explains what the default 'problems' view returns, making the tool easy to distinguish from siblings like azure_aks_overview and azure_aks_pod_logs.

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 default 'problems' view is presented as the triage/high-signal path and other views are described as listing everything, which is clear usage context. However, it never explicitly contrasts this tool with sibling tools such as azure_aks_overview or azure_aks_pod_logs, so an agent must infer when this one should be selected instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by detailing what the overview includes (top exceptions, failing dependencies, slowest operations) and that each entry carries an operation ID for trace handoff, which is useful beyond the structured annotations.

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

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

The description is two sentences with no redundancy. The first sentence front-loads the purpose and content of the overview; the second sentence explains the operation ID handoff to the sibling tool. Every word adds value.

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

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

With no output schema, the description must convey what the tool returns, and it does so comprehensively: request volume, failure rate, failed operations, exceptions, dependencies, slow operations, and operation IDs. It does not detail pagination/limits, but for a triage overview with all parameters documented and annotations covering safety, this is sufficient.

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

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

Schema coverage is 100% per the context signals, and each parameter (role, hours, appInsightsId) already has a descriptive definition in the schema. The description does not add parameter-level semantics beyond implicitly referencing the app and the one-call nature, so the baseline score of 3 applies.

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

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

The description opens with 'One-call triage of an application from Application Insights' and enumerates the exact failure-related data returned: request volume, failure rate, failed operations, exceptions, dependencies, and slow operations. This specific verb-resource pairing clearly distinguishes it from sibling tools like azure_appinsights_trace (which it names) and generic logging/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 clearly positions this as an initial triage tool, and explicitly instructs the agent to pass the sample operation ID to azure_appinsights_trace for full end-to-end transaction details. It does not explicitly state when not to use it or name alternative tools for non-failure investigations, but the context is clear enough for an agent to select it appropriately.

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?

Beyond the readOnly/idempotent annotations, it discloses that results are time-ordered and include request, dependency, exception, and trace data across services. This gives an accurate picture of the call result without an output schema, and there is no contradiction with the 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?

Two information-dense sentences with zero waste. The core result is front-loaded, and the cross-reference to the failures tool is placed at the end.

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

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

For a read-only trace tool with no output schema, the description enumerates what will be returned and in what order, while the schema and annotations handle parameters and side effects. An agent has enough context to call and interpret this tool correctly.

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

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

The schema already covers all three parameters with 100% description coverage. The description adds real value by pointing to azure_appinsights_failures.sampleOperationId and clarifying that operationId is the trace key.

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?

Uses a specific verb ('Shows') with a precise resource ('everything recorded for one operation ID'), enumerates content and ordering, and notes cross-service scope. This clearly differentiates it from service-specific log tools like azure_appservice_logs and azure_containerapp_logs.

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 establishes the use case: trace one operation end-to-end across services, and tells agents where to obtain valid operation IDs. It stops short of explicitly stating when not to use it or naming the alternative for single-service logs.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: it identifies Kudu as the underlying source, explains Linux vs. Windows behavior for each source value, and notes that Windows application logging must be enabled. It does not cover every behavior such as pagination or authentication, but the added detail is meaningful.

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 information-dense but every sentence earns its place: the main verb-resource statement, Linux source semantics, Windows source semantics, and the routing to azure_logs_query for older logs. It is front-loaded and contains 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?

For a read-only log tool with strong annotations and a fully documented input schema, the description covers the key context: source selection, OS differences, a prerequisite, and the sibling tool for older logs. It does not describe the output format, but no output schema exists and the purpose is clear enough for 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 100%, so the baseline is 3 even without elaboration. The description goes beyond the schema by explaining what 'app' and 'platform' mean on Linux and Windows, and it contextualizes the 'lines' parameter with 'most recent log lines.' This adds real value to the bare parameter descriptions.

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

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

The description opens with a specific verb-resource pair: 'Reads the most recent log lines of an App Service or Function app' from Kudu log files. It distinguishes itself from azure_logs_query by explicitly noting the older-logs case, so an agent can tell this tool apart from siblings.

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

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

The description gives concrete when-to-use guidance: this tool reads recent on-disk log lines, and 'For logs older than the files on disk, use azure_logs_query.' It also provides per-OS guidance for the 'source' parameter, including a prerequisite for Windows app logging, making the selection decision explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, lowering the bar. The description adds a meaningful behavioral guarantee: 'App setting and connection string values are never read.' This is valuable context beyond what the annotations provide and helps the agent avoid expecting sensitive values in the output.

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 packed with useful enumerations, including state, runtime stack, plan/scale, configuration, logging, slots, deployments, and functions. It front-loads the verb and target resource, and the final sentence adds an important constraint without any filler.

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

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

With no output schema, the description must communicate what the tool returns, and it does so thoroughly by listing all major sections: state, stack, plan, configuration, logging, slots, deployments, and functions. The explicit statement about not reading secrets also clarifies an important boundary for a potentially sensitive Azure resource.

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

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

Schema description coverage is 100% and the resourceId parameter is already documented as a Microsoft.Web/sites app or sites/slots slot. The description reinforces the resource scope but does not add new semantic detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('Summarizes'), a specific resource type ('App Service or Function app or a deployment slot'), and a clear purpose ('for debugging'). It also enumerates the exact aspects covered, which distinguishes it from sibling tools like azure_appservice_logs or azure_get_resource.

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

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

The phrase 'for debugging' gives clear context for when to use this tool: when an agent needs a broad overview of an App Service, Function app, or slot before digging into logs or metrics. It does not explicitly name alternatives or state when not to use it, so it falls short of a fully explicit routing 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?

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds value beyond annotations by explaining source semantics, the workspace location, and the 'oldest first' ordering. It does not contradict the read-only annotation; 'Reads' is consistent with readOnlyHint=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?

Three dense sentences with zero filler: purpose and workspace first, then source semantics, then filtering and ordering. The most decision-critical info (what the tool reads) is front-loaded and every sentence earns its place.

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

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

For a 6-param read-only tool with 100% schema coverage and no output schema, the description covers the key agent decision points: what it reads, which source to choose, how to filter, and result ordering. Minor gap: it doesn't describe the return format, but for a log reader that is self-evident and acceptable absent an 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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by defining what the source enum values mean concretely ('console' = stdout/stderr; 'system' = revision provisioning, image pulls, probe failures, crashes, scaling) and by mapping 'Filter by revision or by text' to the revision/search parameters. This adds real meaning 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?

States a specific verb+resource ('Reads recent Container App logs') plus the backing store (Log Analytics workspace). It distinguishes itself from log siblings (azure_aks_pod_logs, azure_appservice_logs, azure_logs_query) by defining the two log sources and their content, so an agent can tell what this tool uniquely provides.

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 internal guidance on when to pick 'console' vs 'system' by enumerating what each contains, and explains filtering by revision/text. However, it never names or routes to alternative tools such as azure_aks_pod_logs or azure_appservice_logs, so when-not-to-use-this guidance is left to inference rather than stated explicitly.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral detail beyond this: it explains that the tool retrieves a broad multi-section snapshot, includes restart counts and states of replicas, and scopes to active revisions. This is useful context that annotations do not convey.

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 uses the second sentence to point to the correct sibling tool for logs. The first sentence is long but every listed item represents a distinct part of the returned overview, so the length is justified rather than padding.

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

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

Despite having no output schema, the description enumerates the full scope of the overview: provisioning/running state, ingress, container specs, probes, scale rules, revisions, traffic, and replica restart counts. It also handles the main adjacent need—logs—by naming azure_containerapp_logs. For a one-parameter read-only tool, 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 100% and the sole resourceId parameter is already documented as the resource ID of a Microsoft.App/containerApps app. The description does not add further parameter-level nuance, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Summarizes a Container App for debugging.' It then enumerates the exact categories covered (state, ingress, containers, scale rules, revisions, replicas), making it unmistakable what this tool does and how it differs from log-focused siblings.

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

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

The description gives clear usage context ('for debugging') and explicitly routes console/system log needs to azure_containerapp_logs. It does not exhaustively contrast with azure_get_resource or the other overview tools, but the resource-scoped summary purpose is clear enough for most selection scenarios.

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

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

Annotations already provide a thorough safety profile: readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds no significant operational behavior beyond what annotations cover, aside from reinforcing that subscriptions are readable. No contradiction 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?

Two sentences front-load the output contents and then provide practical call-first guidance. There is no filler, and every phrase earns its place.

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

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

For a zero-parameter, read-only context tool, the description sufficiently explains what it returns, when to call it, and why it matters. There is no output schema, but the listed information—identity, tenant, and readable subscriptions—is enough for an agent to decide whether to invoke the tool.

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

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify; per the zero-parameter baseline this is a 4. The description's mention of subscription IDs is context for the tool's output, not parameter documentation.

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

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

The description uses a specific verb and resource: it 'Shows' the signed-in Azure identity, tenant, and readable subscriptions. This clearly distinguishes it from sibling tools, which focus on logs, metrics, and resource data rather than account context.

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

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

The description gives explicit trigger conditions: 'Call this first when you need a subscription ID, or when another tool reports an authentication or permission problem.' It lacks an explicit 'when not to use' or named alternatives, but the guidance is unambiguous and actionable.

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?

Annotations already declare readOnly, non-destructive, idempotent behavior, so the description only needs to add behavioral context. It does add meaningful specifics: the two-step list-then-run pattern and the fact that it surfaces managed platform diagnostics not available through direct queries. No contradiction with annotations 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 tightly structured: first sentence states the action and scope, second lists the valuable diagnostic categories, third gives the call pattern. Every sentence earns its place with no redundancy or filler.

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

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

For a read-only tool with no output schema, the description covers what the tool does, which resources it targets, why an agent would choose it, and how to sequence calls. It does not describe result shape or pagination, but given the rich annotations and clear workflow, the agent has enough 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 100%, so all three parameters are already documented. The description reinforces the detector parameter's omit-to-list behavior and gives workflow guidance, but it does not add substantive semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb-plus-resource ('Runs Azure's built-in 'Diagnose and solve problems' detectors') and names the exact resource types (App Service, Function apps, Container Apps). It further lists concrete diagnostic outcomes (crashes, restarts, HTTP 5xx, CPU/memory pressure, SNAT exhaustion), making the tool's scope unmistakable and distinguishing it from generic log or metrics siblings.

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

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

The description gives a clear workflow: call without a detector to list detectors, then call again with a detector id. It also signals the appropriate context ('platform data you cannot query yourself'), which implies when to prefer this over raw log/metrics tools, though it does not explicitly name 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral detail beyond that: it searches across all subscriptions, returns resource IDs plus type, location, SKU, and provisioning state, and gives representative Azure resource types. No contradiction with 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 tightly written: one sentence establishes what the tool does, one sentence states return value value and fields, and the example plus common-types list are compact and directly useful. No filler or repetition of the schema.

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

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

For a read-only search tool with no output schema, the description covers the essential context: what can be searched, that it spans subscriptions, what fields come back, how results are useful for downstream tools, and common type values. An agent has enough to invoke it correctly without inspecting other resources.

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

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

The input schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds value by translating the parameter surface into a natural-language filter list, providing a concrete example combining name and type, and mapping common Azure type strings to friendly names like App Service, Functions, and AKS.

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

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

The description clearly states a specific verb and resource: finds Azure resources by name, type, resource group, location, or tag across all subscriptions at once. It also describes what is returned. It does not explicitly contrast itself with sibling tools like azure_resource_graph_query or azure_get_resource, so sibling differentiation is implied rather than stated.

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

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

The description implies when to use the tool: when you need to discover resources across subscriptions by structured filters and obtain IDs for other tools. It does not state when not to use it or explicitly mention alternatives, even though sibling tools such as azure_resource_graph_query and azure_get_resource likely overlap.

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 four annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false) already covering the safety and side-effect profile, the description adds genuinely useful behavior beyond them: 'Secret values are masked' warns the agent not to expect live credentials in the response, and the child-resource scope clarifies what 'any resource type' includes. No contradiction with annotations is present. It stops short of describing error behavior for nonexistent resources, but the masked-secrets disclosure is a meaningful value-add.

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

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

Four sentences with zero waste: primary behavior first, then scope, then the critical caveat, then the sourcing hint. Each sentence carries distinct information and the most important facts are front-loaded ahead of the auxiliary guidance. This is appropriately sized for a two-parameter read-only tool.

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

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

For a low-complexity tool (2 params, 1 required, no nested objects), the description covers all invocation-relevant ground: what it returns and its field inventory (partially compensating for the absent output schema), scope boundaries, a response caveat, and how to obtain the one required parameter. The four annotations complete the safety picture. The only omission—error handling for missing resources—is minor and does not affect correct invocation.

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

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

Schema description coverage is 100%, with both resourceId (including a full path example) and apiVersion (including default behavior) already documented, so the baseline is 3. The description contributes one extra parameter-level insight—that resourceId should be sourced from azure_find_resources—which helps the agent obtain the required argument correctly. That lifts it a notch above the baseline.

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: 'Returns the full Azure Resource Manager definition of one resource,' then enumerates the content (configuration, SKU, identity, networking, state). Explicitly noting it works for 'any resource type, including child resources such as deployment slots' distinguishes it from the resource-specific siblings like azure_aks_overview and azure_containerapp_overview. The 'one resource' scope cleanly separates it from the discovery tools azure_find_resources and azure_resource_graph_query.

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, actionable context: it is the generic full-definition lookup for any resource, and it explicitly directs the agent to 'Get the resource ID from azure_find_resources,' naming the exact sibling that supplies the required parameter. However, it never states when not to use it or that resource-specific overview tools exist as alternatives for deeper domain views, so it lacks explicit 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?

Annotations already cover read-only, non-destructive, idempotent behavior. The description adds valuable behavioral context by explaining how the scope parameter affects query results (whole workspace vs. specific resource) and provides example tables for different resource types, going beyond annotation-provided safety hints.

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 action. Every sentence earns its place: scope explanation, table examples, a query example, and a pointer to the helper tool. It is concise despite its length, 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 complex tool with no output schema, the description covers scope behavior, query examples, and a scope-finding helper. It is sufficiently complete for an agent to call it correctly, though it does not describe the return format or error handling, which are minor gaps given the annotations and schema coverage.

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 descriptions cover all 4 parameters (100% coverage), but the description enriches the scope parameter with detailed semantics about what each scope type queries and gives a concrete query example. This adds meaning beyond the schema's generic descriptions, though hours/limit are not elaborated beyond schema defaults.

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

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

The description clearly states 'Runs a KQL query against Azure Monitor Logs' and elaborates on scope types (workspace, Application Insights, or any resource), making the tool's function unambiguous. It implicitly differentiates from specialized siblings by being the general-purpose KQL tool, and the scope semantics are precise.

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 context on when to use this tool (for arbitrary KQL queries) and explicitly points to azure_telemetry_locations for finding the right scope. However, it does not explicitly mention when to prefer specialized siblings like azure_appservice_logs or azure_containerapp_logs, so it lacks explicit 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds behavioral detail beyond those: the return shape (min/avg/max/latest per series plus downsampled series), the list mode, and dimension-splitting via filter. It does not mention response limits or pagination, but these are minor for a read-only metrics 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 compact and information-dense: it states the resource, enumerates typical metrics, explains both call modes, describes the return shape, and gives a concrete example. Every sentence earns its place, and the most important facts 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 100% parameter schema coverage, strong annotations, and no output schema, the description provides a good picture of behavior and returns. It explains list mode, aggregation shape, downsampling, and filtering. It could mention the output structure more explicitly, but the tool is simple enough that this is a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter behavior: omitting metrics triggers a listing mode, and filter is used to split by dimension (e.g., 'Instance eq \'*\''). The inline example ties resourceId, metrics, and hours together, going beyond the schema's field-level definitions.

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

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

The description clearly identifies the tool as reading platform metrics for any Azure resource and gives concrete examples (CPU, memory, HTTP 5xx, response time). It distinguishes this from sibling tools centered on logs, activity, or resource health by focusing specifically on platform metrics.

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 two usage modes: omit metrics to list available metrics, or provide metrics to retrieve aggregations and time series. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can infer when metrics are the right data source.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds useful behavioral context: the 14-day lookback window, the configuration-change scope, and the returned detail fields. It does not discuss pagination or data availability delays, but for a read-only tool this is a minor gap.

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

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

Two tight sentences with no filler: the first front-loads the verb, resource, scope, and time range, and the second gives a concrete diagnostic use case. Every clause adds value.

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

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

For a read-only list tool with a small, fully documented parameter set and no output schema, the description covers what it returns, the supported scopes, the time window, and the motivating use case. Nothing an agent needs to call it 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 description coverage is 100%, so the schema fully documents all three parameters. The description adds context about what the list contains but no new parameter-level detail, matching the baseline for high schema coverage.

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

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

The description uses a specific verb ('Lists configuration changes') with an explicit resource and scope ('to a resource, or to every resource in a resource group or subscription'). It names the exact output fields (what changed, before/after values, who, client), making it clearly distinguishable from sibling log/telemetry 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 line 'Use it to answer "what changed before this broke?"' gives an explicit, concrete use case. It does not, however, mention when not to use it or point to an alternative sibling, so it stops short of the full when/when-not 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces this by calling the index 'read-only.' It adds useful behavioral context: the data source spans all accessible subscriptions, key tables are enumerated, and example queries show the kind of KQL usage expected. It does not mention pagination or API limits, but annotations cover the core safety profile.

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: definition, useful tables, concrete examples, and routing to an alternative. Each sentence contributes meaningful guidance without unnecessary fluff.

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

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

For a complex KQL query tool with no output schema, the description provides table guidance, example queries, and scope context, which is strong. It does not explain return shape or pagination flow, but the schema covers parameters and arbitrary KQL output is hard to fully specify; overall an agent has enough to call this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description's examples indirectly show how the query parameter is used, but it adds no explicit detail about top, skipToken, subscriptionIds, or managementGroupIds beyond what the schema provides. Baseline 3 is appropriate.

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

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

Description states a specific verb ('Runs a KQL query') and a specific resource ('Azure Resource Graph'), and clarifies scope ('every resource across your subscriptions'). It also explicitly distinguishes itself from azure_find_resources, so an agent can tell them apart.

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 concrete guidance on when to use this tool and when not to: 'Use azure_find_resources for simple lookups.' It also provides useful table names and example queries, making the intended use case clear and separating it from 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. It adds value by specifying the output includes availability, recent changes with Azure's stated reason, and active service issues—details not covered by annotations. No contradiction 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?

Two sentences with no filler. The primary function is stated first, followed by usage context. Every phrase earns its place, and the description is front-loaded with the core purpose.

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

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

For a read-only health check with a single parameter and no output schema, the description covers the essential information: what it returns and when to use it. It's complete enough for an agent to invoke correctly without additional 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?

The schema already documents resourceId as 'Resource ID to check' with 100% coverage. The description adds no additional parameter semantics beyond implying the resource is Azure-managed. Since the schema handles it, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool reports Azure's own health assessment of a resource, including current availability, recent changes with reasons, and active service issues. It explicitly frames the purpose as distinguishing platform problems from application problems, which distinguishes it from sibling tools like azure_activity_log or azure_metrics.

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 to use this tool early when an app is down, to differentiate platform vs. application issues. It implies the alternative is to check application logs or other diagnostics, though it doesn't name specific sibling tools. This is clear enough for an agent to choose appropriately.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral detail by listing the types of telemetry sinks it resolves and stating that it returns both resource IDs and tables to query.

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, information-dense, and front-loaded with the core action. The second sentence clearly states when to invoke the tool. No filler or redundant phrasing is present.

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 resource-discovery tool with no output schema, the description explains what will be returned, how to use the results, and when to call it. It does not cover edge cases like unsupported resources or absence of telemetry configuration, but the core information an agent needs is presente.

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 single parameter resourceId has 100% schema description coverage, so the baseline is 3. The description repeats the resource type examples from the schema but does not add substantial new semantics beyond what the schema already 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 tool's purpose: finding where a resource's logs and telemetry are stored. It enumerates specific storage destinations and explicitly distinguishes this discovery tool from log-querying capabilities by saying it returns resource IDs and table names to use with 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 gives a clear usage instruction: call this before querying logs for a resource you have not looked at yet. It does not explicitly mention when not to use it or name alternative discovery tools, but the placement as a prerequisite to azure_logs_query and azure_appinsights_failures provides strong contextual guidance.

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