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

Discloses the key behavioral constraint (only cancels Running/Waiting runs) but lacks details on consequences, permissions, rate limits, or error handling. As no annotations exist, the description should do more to explain 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?

Two sentences with no fluff. Front-loads the core action, then adds constraints and prerequisite guidance. Every sentence is valuable.

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 output schema and simple mutation operation, the description covers purpose, constraints, and prerequisite lookup. Missing information on return values or errors, but adequate for a cancellation 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 covers parameters 100%, but description adds critical semantic info: workflowName is required for Standard SKU, which is not in the schema's required list. This extra context improves parameter understanding 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?

Clearly states the tool cancels running/waiting workflow runs with specific verb and resource. Does not explicitly differentiate from sibling tools like resubmit_run or search_runs, but the status conditions help distinguish.

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 explicit conditions for cancellation (only Running or Waiting status) and suggests finding runs first using list_run_history or search_runs. Also notes the requirement for workflowName in Standard SKU, giving clear contextual 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 provided, so description carries full burden. Discloses that the target must exist, workflow name must be new, and connections need reconfiguration. Implies non-destructive cloning, though not explicitly stated. Could mention that the source workflow is not modified. Overall transparent enough for agent to understand 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?

Four sentences, each serving a distinct purpose: purpose statement, critical prerequisite, workflow context, and post-cloning action. No fluff. Could be slightly shorter by combining sentences, but current structure is clear and front-loaded with the important warning.

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 input and process well but lacks any mention of return value or output behavior. Since no output schema exists, the agent would need to know whether the tool returns the cloned workflow details, a success status, or something else. Also, no indication of asynchronous execution or expected duration. This gap reduces completeness for a tool with 8 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 baseline is 3. The description adds value by explaining the default behavior for targetSubscriptionId and targetKind, and emphasizing prerequisites for target parameters. This helps the agent understand defaults and constraints 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 uses a specific verb 'clone' and clearly identifies the resources involved: Consumption Logic App workflow to Standard Logic App. It distinguishes from siblings like create_workflow and validate_clone_workflow by focusing on the migration scenario.

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 instructs to run validate_clone_workflow first for compatibility checks. States preconditions (target Standard must exist, target workflow name must not exist) and post-cloning step (reconfigure connections). The description also mentions that targetSubscriptionId defaults to source subscription and targetKind defaults to Stateful, guiding parameter choices.

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 discloses key behaviors: OAuth connectors return a consent link that must be opened in a browser, and parameter-based connectors require direct parameters. It does not cover idempotency or error handling, but the disclosed behavior is sufficient for most use cases.

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 paragraph of 5-6 sentences, front-loaded with purpose, then logically covering OAuth vs parameter distinction and examples. No unnecessary words, well-structured.

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

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

Given the complexity (7 params, no output schema, no annotations), the description covers the main behavioral and parameter aspects. It explains the consent link for OAuth and lists common connectors. It could mention idempotency or result handling after consent, but overall it is reasonably 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 100%, so baseline is 3. The description adds value by categorizing parameters for OAuth vs parameter-based connectors, providing specific examples (SQL: server, database, username, password; ServiceBus: connectionString). This goes beyond the 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 tool creates a new API connection for a managed connector, with specific examples (azureblob, sql, servicebus, office365). It distinguishes from sibling tools like create_workflow (different resource) and test_connection (testing vs creation).

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 (creating connections) and provides detailed guidance on OAuth vs parameter-based connectors, including specific parameter examples. However, it does not explicitly state when not to use it or compare to alternatives like test_connection.

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 explains the creation behavior for both SKUs, including required parameters and the need for a valid definition JSON. However, it does not mention potential side effects like overwriting existing resources or rate limits, which would improve 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 front-loaded with the main purpose, then efficiently covers SKU differentiation and important usage notes. Every sentence adds value, and there is no redundant information. It is well-structured for an agent to quickly 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 8 parameters, full schema coverage, and no output schema, the description adequately covers all necessary context for correct invocation. It explains the two main usage paths and the critical prerequisite for connector actions, making it complete for an 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?

Schema coverage is 100%, but the description adds significant value beyond the schema: it explains SKU-specific requirements for location, workflowName, and LogicAppName, and provides a detailed example for the complex 'connections' parameter. This reduces ambiguity for the agent.

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 that the tool 'Create a new workflow' and distinguishes between Consumption and Standard SKU, specifying what resource is created. It provides a specific verb and resource, differentiating from sibling tools like clone_workflow or update_workflow.

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 when to use for each SKU and provides a crucial prerequisite: use get_connector_swagger for connector actions. It also gives guidance on the 'connections' parameter for Consumption SKU. This helps the agent decide when to invoke 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, the description effectively discloses key behaviors: SKU-dependent effects (deletes entire app vs. specific workflow) and irreversibility. It adds context beyond basic deletion, though it could mention permission requirements.

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 clear, front-loaded sentences efficiently convey purpose, SKU difference, and caution, with no unnecessary 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 covers behavioral differences and irreversibility but lacks details on return values, error handling, or permission requirements. Given no output schema and no annotations, some completeness gaps remain.

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%, but the description adds value by explaining that workflowName is required for Standard SKU and providing SKU context. This enhances parameter understanding beyond the 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 'Delete a workflow' and differentiates between Consumption (deletes entire Logic App) and Standard (deletes specific workflow), making the tool's purpose highly specific and distinct from siblings like disable_workflow.

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 'Use with caution as this action cannot be undone,' implying careful usage, but does not provide explicit guidance on when to use this tool versus alternatives like disable_workflow or other deletion methods.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: in-progress runs continue, Consumption disables entire Logic App, Standard disables specific workflow. It lacks permissions or side effects, but the core behavior is well covered.

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 wasted words. The first sentence states the primary action, the second adds behavioral nuance. 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?

Given no output schema, the description adequately covers the primary behavior. It explains the effect on triggers and ongoing runs, and distinguishes between SKUs. Missing return value info, but not critical for a disable 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 100%, so the schema already documents all parameters. The description mentions the parameters but adds no additional semantics beyond what's in the schema.

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

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

The description uses specific verbs ('Disable', 'stopping') and identifies the resource ('active workflow'). It clearly distinguishes from siblings like enable_workflow and delete_workflow by specifying the effect (stop processing triggers, in-progress runs continue).

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

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

The description provides clear context for when to use the tool (for disabling an active workflow) and explains differences between Consumption and Standard Logic Apps. However, it does not explicitly state when not to use or list 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?

No annotations are provided, so the description carries full burden. It states the effect (enabling a workflow) but does not mention idempotency, prerequisites, or what happens if the workflow is already enabled. For a simple enable operation, this is adequate but could be more transparent.

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

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

Two sentences with no wasted words. The main action is front-loaded, and the SKU-specific detail is provided concisely. 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?

Given the simplicity of the operation (enable), the description covers the essential purpose and the SKU distinction. No output schema exists, but the return value is implied. It could mention potential errors or idempotency, but overall complete for a basic tool.

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

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

The input schema has 100% description coverage, but the description adds value by explaining that 'workflowName' is required for Standard SKU. This clarifies the parameter's conditional requirement beyond the schema's static description.

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

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

The description uses specific verb 'Enable' and resource 'workflow', and clearly distinguishes behavior between Consumption and Standard Logic Apps. This differentiates it from sibling tool 'disable_workflow' and from other workflow manipulation 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 clear context on when to use the tool (to enable a disabled workflow) and explains the difference between Logic App SKUs. While it doesn't explicitly list alternatives or when not to use it, the context is sufficient for an agent to decide.

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?

The description explains the core behavior: 'Fetches content from inputsLink/outputsLink URLs.' With no annotations, this is helpful but insufficient. It does not disclose potential side effects, authorization requirements, rate limits, or the nature of the fetched data (e.g., size limits, pagination).

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 two sentences that cover purpose, technical detail, and usage motivation. It is front-loaded with the action and provides essential information without 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 has 7 parameters and no output schema, the description should explain what the returned data looks like (e.g., format, structure). It only mentions 'actual input/output data' which is vague. Users debugging transformation issues need to know the response shape, making this description 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 coverage is 100%, so baseline is 3. The description adds value by clarifying that 'workflowName is required for Standard SKU,' which provides critical usage context beyond the schema. The type enum is already clear from 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 'Get the actual input/output data for a run action' and specifies it fetches from inputsLink/outputsLink URLs. It differentiates the tool's purpose from generic run data retrieval but doesn't explicitly distinguish it from action-specific siblings like get_action_repetitions or get_action_request_history.

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 by stating 'For Standard SKU, workflowName is required' and labels the tool as 'Essential for debugging data transformation issues.' However, it lacks guidance on when not to use it or how it compares to alternatives among the many 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, the description carries the burden. It discloses what data is returned (status, inputs, outputs, trackedProperties) and a conditional requirement. It implies read-only diagnostic use, but does not explicitly state no side effects or permissions needed.

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: first states purpose, second adds detail and context. Every sentence is informative with no fluff. Front-loaded with the core action.

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 7 parameters, no output schema, and no annotations, the description effectively covers purpose, usage context, returned data fields, and an important conditional requirement. It is sufficient for an agent to understand and 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?

Schema coverage is 100%, baseline is 3. The description adds value by clarifying that workflowName is required for Standard SKU, which is not evident from schema alone. This extra context raises the score.

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 'Get' and the resource 'iteration details for actions inside loops', and explicitly mentions the loop types (ForEach, Until). It distinguishes from siblings like get_scope_repetitions by specifying loop iterations.

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

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

The description provides clear context for when to use the tool: 'Essential for debugging loop failures'. It also notes a prerequisite for Standard SKU (workflowName required). However, it does not explicitly list alternatives or scenarios to avoid.

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

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

No annotations are provided, so the description carries the full burden. It discloses that actual HTTP calls, headers, status codes, and timing are shown, and retries are included. However, it does not mention safety, authorization needs, or any side effects, which would improve 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?

Two sentences: first states purpose and scope, second adds a usage condition and typical use case. No redundant information, and key 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 no output schema, the description explains what is returned (HTTP call details). It also notes a SKU-specific requirement. However, it could mention pagination or response size limits to be fully complete for a history retrieval tool.

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

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

Schema description coverage is 100%, meaning all parameters already have descriptions. The tool description adds little beyond the schema; it only reiterates the workflowName requirement. With complete schema coverage, baseline is 3, and the description does not significantly enhance parameter understanding.

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 'Get' and clearly identifies the resource: HTTP request/response details for connector actions, including retries. It focuses on debugging API failures, which distinguishes it from sibling tools like get_run_actions or get_action_repetitions.

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 a condition (workflowName required for Standard SKU) but does not explicitly state when to use this tool versus alternatives or when not to use it. The context is clear for debugging, but no exclusions or comparisons are provided.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the tool provides guidance but does not describe behavioral traits such as whether the data is static or dynamic, any freshness guarantees, or if there are any limits. The description is adequate but lacks depth.

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: the first states the primary purpose, and the second provides usage guidance. There is no redundant information, and it is front-loaded with the core function. 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?

Given no output schema, the description could hint at the return format. It does not mention the output type, which is a gap. However, the tool is simple with one parameter, so the description is largely complete for the use case but could be improved.

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 the topic parameter's enum description already explaining the values. The tool description echoes these without adding new meaning beyond the schema, so it meets the baseline but does not excel.

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: 'Get guidance for creating and modifying Logic Apps workflows.' It specifies the verb and resource, and distinguishes from sibling tools like get_workflow_definition or get_troubleshooting_guide by focusing on authoring guidance across three specific subtopics.

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 when to use the tool: 'Call this when helping users build workflows, understand connector patterns, or set up deployment pipelines.' This provides clear usage context, though it does not mention when not to use it or name alternative 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, the description carries the transparency burden. It lists returned data types but omits authorization requirements, error handling, or side effects (likely none). Adequate but not comprehensive.

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 efficient sentences: first lists purposes and contents, second provides actionable guidance. 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?

The description covers the tool's output partially but lacks details on output format, prerequisites, or error conditions. With no output schema, more context would be beneficial. Adequate for a simple 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 100% with clear parameter descriptions. The tool description adds no additional semantic meaning beyond 'specific API connection'. 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 specifies the verb 'get' and the resource 'API connection', detailing the included information (authentication status, configuration, API reference) and distinguishing it from test_connection.

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 mentions an alternative (test_connection) for verification, but does not provide when-to-use guidance for other sibling tools like get_connections or list_logic_apps.

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 explains that connections are shared resources used for authentication, but does not disclose permissions, pagination, or return format. Some behavioral context is provided, but it is minimal.

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, no wasted words. The purpose is front-loaded. Every word earns its place.

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

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

No output schema and no annotations. The description explains what connections are and hints at output by mentioning 'more info' options, but does not describe return values, pagination, or filtering. Adequate but with 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?

Both parameters have schema descriptions (subscriptionId, resourceGroupName). Schema coverage is 100%, so baseline is 3. The description adds no additional 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 it lists API connections (with examples like Office 365, SQL, Service Bus) in a resource group. The verb 'List' and resource 'API connections' are specific. It distinguishes from siblings by mentioning get_connection_details and test_connection for more info.

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 tells when to use this tool and directs to get_connection_details or test_connection for further information. However, it does not state prerequisites or when not to use it, leaving some ambiguity.

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

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

No annotations provided. Description does not disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or prerequisites (e.g., connector must exist). For a tool with no annotations, this is a significant gap in transparency.

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

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

Two sentences, first directly states purpose with examples, second emphasizes importance. No unnecessary words, front-loaded with key information. Excellent for a tool that may be used frequently.

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 output schema, the description does not explain the return format (e.g., JSON OpenAPI spec). For a tool returning a complex structure, more detail on output would improve completeness. However, it is sufficient for its stated purpose of discovering action paths.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds examples of connector names and location format, but these are already implied by the schema. No additional semantic value beyond what the schema provides, so 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 retrieves the OpenAPI/Swagger definition for a managed connector, with specific examples like msnweather, sql, etc. It distinguishes itself from sibling tools like get_workflow_swagger by targeting connector definitions specifically for discovering action paths.

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 says it is 'ESSENTIAL for discovering correct action paths when creating or updating workflows with connector actions,' providing clear when-to-use context. Does not mention when not to use, but the purpose is specific enough to differentiate.

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

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

With no annotations provided, the description carries the burden of behavioral transparency. It clearly states the tool is read-only by describing what it shows (traces) and does not mention any side effects. It adds context about required fields for Standard SKU, which is helpful.

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 long with no wasted words. It front-loads the action ('Get...') and efficiently conveys what the tool does, what it includes, a conditional requirement, and its primary use case.

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 output schema, the description gives a reasonable hint of the return shape (expression text, result, errors). It covers the essential behavioral and usage context. While it could mention pagination or list format, the tool is simple enough that 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%, so the description adds value beyond the schema by explaining the conditional requirement for workflowName in Standard SKU and giving examples of expressions (@body(), @variables()). This helps an agent understand the parameter semantics more deeply.

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: 'Get expression evaluation traces for an action.' It specifies what is shown (expression text, result value, errors) and distinguishes it from siblings like get_action_io by focusing on expression evaluation rather than inputs/outputs.

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 indicates when to use this tool: 'Essential for debugging expression failures.' It also provides a prerequisite: 'For Standard SKU, workflowName is required.' While it does not explicitly list alternatives, the context is clear enough for an agent to decide.

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 states the output includes specific version and diagnostics info but does not disclose behavioral traits like read-only nature, potential errors if applied to non-Standard SKU, or any 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?

Two sentences, no wasted words. Information is front-loaded and clear.

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 output schema, the description sufficiently lists key output items but lacks details on return format, error conditions, or what 'diagnostics' encompasses. Adequate but incomplete for deeper understanding.

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

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

Schema coverage is 100% with standard parameter descriptions (subscriptionId, resourceGroupName, logicAppName). The description does not add additional meaning beyond the schema, so 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 clearly states the tool gets host status for a Standard Logic App, listing specific details (runtime version, extension bundle version, diagnostics). This distinguishes it from sibling tools like get_run_details or get_workflow_definition, which target different aspects.

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 notes the tool is 'Only available for Standard SKU', a useful constraint, but does not provide explicit guidance on when to use this over alternative tools (e.g., get_workflow_definition for definitions or get_workflow_triggers for triggers).

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; description implies a read-only, non-destructive operation. It does not disclose additional behavioral traits like response format, permissions, or rate limits. Adequate but not exhaustive.

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

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

Two sentences, no extraneous content. Purpose is front-loaded and each sentence adds distinct 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?

Tool is simple with one parameter but lacks specification of output format (e.g., plain text or structured JSON). Given no output schema, the description should clarify what the agent can expect.

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 provides full coverage with enum and description. Description adds value by stating the output is from official Microsoft documentation, which enhances understanding 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 the tool retrieves reference documentation for Logic Apps, specifying two concrete use cases (tool usage details and SKU differences). It effectively distinguishes from sibling get_* 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 explicit scenarios when to use ('comprehensive tool usage details' and 'differences between Consumption and Standard SKUs'). Lacks explicit when-not-to-use but context from sibling tools implicitly covers 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?

No annotations are present, so the description must convey behavioral traits. It implies a read operation (get details) and specifies what data is returned (status, timing, trackedProperties). However, it does not mention any potential limits, pagination, or authorization requirements, which would enhance transparency. Still, given the simplicity of a get tool, a 4 is reasonable.

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, consisting of two sentences that front-load the purpose, then add conditional guidance and an alternative tool reference. 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?

While there is no output schema, the description lists what the tool returns (status, timing, trackedProperties). Given the large number of sibling tools (41), this description provides enough context to differentiate. It could be improved by noting any default behavior or limits, but it is largely complete for a get-action-details tool.

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

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

The input schema has 100% coverage with descriptions for all 6 parameters. The description adds value by noting that workflowName is required for Standard SKU, which is not apparent from the schema alone. This extra context helps the agent select and fill parameters correctly.

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 a clear verb ('Get') and resource ('action execution details for a specific workflow run'), listing specific fields (status, timing, trackedProperties). It also distinguishes itself from the sibling tool get_action_io by noting what that tool does instead.

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

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

The description explicitly states a condition ('For Standard SKU, workflowName is required') and provides a clear alternative ('Use get_action_io to see actual inputs/outputs for an action'). This guides the agent on when to use this tool versus a sibling.

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 states the tool returns status, timing, and error summary, implying a read operation. However, it does not explicitly confirm read-only nature or mention authentication or rate limits, which would strengthen 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?

Two sentences with no wasted words. First sentence conveys core purpose and output summary; second sentence adds critical usage condition and alternative tool. 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?

Given no output schema, the description provides a high-level summary of return fields (status, timing, error summary). It covers the essential context for usage but lacks detail on exact structure or potential errors. Adequate for a read tool of moderate complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying that 'workflowName' is required for Standard SKU, which is a conditional constraint not evident from the schema alone. This enhances parameter understanding.

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 retrieves detailed information about a specific workflow run, including status, timing, and error summary. It distinguishes itself from sibling 'get_run_actions' by explicitly noting that the alternative tool shows which action failed.

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 on when to use this tool vs. alternatives: it notes that for Standard SKU, workflowName is required, and directs users to 'get_run_actions' to identify specific failed actions. This sets clear usage boundaries.

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 partially fulfills behavioral disclosure by listing output fields (branch executed, status, trackedProperties). However, it omits important traits such as whether the operation is read-only, any required permissions, rate limits, or error handling.

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 long, front-loads the purpose, and contains no redundant words. Every sentence 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?

Given the lack of output schema and moderate parameter count (6), the description adequately explains what the tool does and its scope. It could be more complete by mentioning output format or pagination, but the core information is 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?

The input schema has 100% coverage for parameter descriptions, but the tool description adds meaningful context by specifying that workflowName is required only for Standard SKU, which is not indicated in the schema. This extra semantic value raises the score above 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 clearly states the tool retrieves execution details for scope action iterations (Scope, Switch, Condition) and specifies what it shows (branch executed, status, trackedProperties). This distinguishes it from siblings like get_action_repetitions or get_run_actions.

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 conditional usage requirement (workflowName required for Standard SKU) which adds context. However, it does not explicitly state when to use this tool over alternatives 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 full weight. It explains the return value (URL with SAS token) and a conditional requirement. It does not mention side effects, but as a read-only operation this is acceptable.

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

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

Three sentences, each contributing essential information: purpose, return value, condition, and alternative. No wasted words.

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

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

For a simple get operation with 5 parameters (4 required) and no output schema, the description covers the return type, a key condition, and an alternative. Lacks details like URL format or expiration, but overall 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%, so baseline is 3. The description adds value by clarifying that workflowName is conditionally required (for Standard SKU), which is not evident from 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 clearly states the tool gets a callback URL with SAS token for request-based triggers (HTTP, manual). It distinguishes from sibling tools like run_trigger and is specific about the 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?

Provides explicit guidance on when workflowName is required (Standard SKU) and advises using run_trigger instead of calling the URL directly, giving context on appropriate use. Could be improved by specifying when not to use this tool.

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

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

No annotations are provided, and the description only implies read-only behavior. It does not disclose any behavioral traits such as permissions required, rate limits, or whether the data is transient.

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

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

The description is two sentences with zero wasted words, front-loaded with purpose and use case.

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 explains the return includes firing, success, and failure status, but without an output schema, more detail about the response structure would be helpful. Adequate but not fully complete.

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

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

Schema coverage is 100%, so the description adds no additional meaning beyond the schema. 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 retrieves execution history of a specific trigger, showing firing, success, and failure events. This distinguishes it from siblings like get_run_details (runs) and list_run_history (runs).

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 it is essential for debugging workflow failures, implying when to use. However, it does not provide explicit when-not-to-use or compare with alternatives like get_run_actions or list_run_history.

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 does not disclose behavioral traits like read-only status, rate limits, or that it returns static guidance. For a troubleshooting guide tool, this is adequate but could be improved.

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-loaded with purpose. First sentence states the action, second sentence gives usage scenarios. No filler or redundant information.

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

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

For a single-parameter tool with no output schema, the description covers purpose and usage well. It doesn't explain the return format, but the name implies a textual guide, which is sufficient for the complexity level.

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 overarching context about when to call, but the parameter 'topic' is already fully described in the schema (100% coverage) with enum values and descriptions. The description does not add new 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 clearly states 'Get troubleshooting guidance for Logic Apps issues' with specific verb and resource. It distinguishes itself from sibling tools like get_run_details or get_workflow_definition by focusing on guidance and patterns rather than raw 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?

Explicitly tells when to call: 'when debugging failed runs, expression errors, connection problems, or to understand platform limitations.' This provides clear context, though it doesn't explicitly list when not to use or mention alternative 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?

Without annotations, the description reveals key behavioral traits such as SKU-dependent parameter requirements and that it returns the full workflow definition JSON. It implicitly indicates a read operation, but could be more explicit about it being non-destructive and the nature of the response.

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 concise sentences, front-loaded with the core purpose, and every word 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?

Given no output schema or annotations, the description covers the essential functional details: what it does, SKU-specific usage, and a pointer to the related modify tool. It lacks explicit error conditions or response format details, but is adequate for the tool's complexity.

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

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

Schema coverage is 100% and the schema descriptions already contain the same SKU condition for workflowName. The tool description adds no new information beyond the schema, meeting the baseline for high coverage but not exceeding it.

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

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

The description clearly states the action (Get the full workflow definition JSON) and the resource (Logic App workflow), distinguishing between Consumption and Standard SKUs. It immediately differentiates from sibling tools like clone_workflow or update_workflow.

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 when-to-use instructions for both SKU types (omit or include workflowName) and offers an alternative (use update_workflow to modify). This gives clear context for the agent to decide when to invoke this tool.

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

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

Without annotations, the description carries the full burden. It clearly states the output ('returns detailed sequences of tool calls') and its role as a first-step planning tool. No side effects are implied, and no contradictory information 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, zero waste. The first sentence states purpose, the second provides usage guidance and output description. Every word is functional and necessary.

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

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

For a simple one-parameter tool with no output schema, the description fully covers purpose, usage, and expected output. It is complete and leaves no ambiguity about what the tool does or when to invoke it.

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

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

Schema coverage is 100%, so baseline is 3. The description's examples reinforce parameter usage but do not add new semantic details beyond what the schema already provides for each enum value.

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 returns step-by-step instructions for common user requests, with specific examples like 'why is my workflow failing?'. It distinguishes itself from siblings by instructing 'CALL THIS FIRST' and by focusing on high-level questions, contrasting with tools like get_troubleshooting_guide which likely address specific errors.

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

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

Explicit guidance is given on when to use the tool ('CALL THIS FIRST when a user asks high-level questions...') with concrete examples. It lacks explicit 'when not to use' or alternative tool names, but the provided context is sufficiently directive for an agent.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It implies a read operation ('Get') but does not explicitly state it is non-destructive, mention required permissions, or describe potential side effects. The description focuses on content rather than safety.

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, no redundant phrases. It front-loads the core action and includes both content details and a practical use case. Every sentence contributes meaning 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?

With no output schema, the description partially compensates by stating what the Swagger definition shows (trigger schemas, request/response formats). However, it does not describe the return format (e.g., JSON OpenAPI spec), potential errors, or required Azure permissions. Given the tool's complexity, more context would be beneficial.

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%, providing a baseline of 3. The description adds value by clarifying that workflowName is required for Standard SKU, which is not reflected in the schema's optionality. This contextual nuance enhances parameter understanding 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 clearly states the tool retrieves the OpenAPI/Swagger definition for a workflow and specifies what it shows (trigger schemas, request/response formats). It is distinct from siblings like 'get_workflow_definition' (returns internal JSON) and 'get_connector_swagger' (for connectors), though it does not explicitly differentiate itself.

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 usage condition ('For Standard SKU, workflowName is required') and a use case ('Useful for API documentation or generating client SDKs'). However, it lacks guidance on when not to use it or alternatives among sibling tools, leaving the agent to infer 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?

No annotations are provided, so the description bears the full burden. It implies read-only behavior ('Get'), adds a conditional requirement (workflowName for Standard SKU), but does not explicitly state side effects, authorization needs, or rate limits. The description is transparent enough for safe 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?

The description is two sentences highly front-loaded with the core purpose, includes conditional usage, and directs to alternatives. Every sentence is essential, 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?

The description covers the purpose, conditional parameter requirement, and alternative tools. It lacks explicit detail on the return format (e.g., list of triggers or single object) but is adequate given no output schema and the clarity of the tool name.

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

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

Schema coverage is 100%, so baseline is 3. The description adds that workflowName is required for Standard SKU, but this is already stated in the schema property description. No additional meaning is provided 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 'Get trigger information for a workflow including last/next execution times,' specifying a concrete verb ('Get') and resource ('trigger information'), and provides distinct details (execution times) that set it apart from sibling tools like run_trigger and get_trigger_history.

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 usage guidance: 'For Standard SKU, workflowName is required' and directs the agent to alternatives ('Use run_trigger to manually fire a trigger, or get_trigger_history to see past executions'), clearly defining when to use this tool versus its siblings.

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 the burden. It discloses the Consumption-only constraint but does not detail behavior such as idempotency, read-only nature, or error handling for missing version IDs.

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-loaded with the main action, no unnecessary words. Every sentence 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?

No output schema, but description doesn't explain return value format (definition). However, 'definition' is self-explanatory, and the tool's purpose is clear. Could be more complete but adequate for a retrieval 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 100% with descriptions for all parameters, so description adds minimal extra meaning beyond the schema. Mention of using list_workflow_versions for versionId context is helpful but not significant.

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 the tool retrieves a specific historical version's definition, uses clear verb+resource, and distinguishes from sibling tool list_workflow_versions by directing to it for listing versions.

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 notes the tool is only for Consumption Logic Apps and directs to sibling for listing versions, providing good context on when to use it. Slightly less explicit on when not to use, but still strong.

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 explains the tool invokes operations to fetch data, but does not state whether operations are read-only or have side effects, nor mention authentication or error behavior. Adequate but lacks depth.

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 sections: purpose, when to use, workflow, examples. Front-loaded and informative, though slightly lengthy. Every sentence contributes.

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 output schema and no annotations, the description effectively explains purpose, usage, and common scenarios. Covers workflow integration and parameter behavior. Lacks details on return format and error handling, but sufficient for authoring 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?

Input schema covers all parameters with descriptions (100% coverage). Description adds value by mapping operationId to real examples (e.g., 'GetTables'), explaining the 'parameters' property as operation-specific, and contextualizing usage. Not just repeating 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 tool invokes dynamic operations on API connections to fetch data like dropdown values, schemas, or metadata. It distinguishes itself from siblings like get_connector_swagger (which discovers operations) and get_connections (which finds connections).

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

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

Explicit 'WHEN TO USE THIS TOOL' section lists conditions: after getting swagger, to list resources, get schema, etc. Workflow steps show integration with other tools, and examples clarify 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?

Lacks annotations, so description bears full burden. It mentions that both SKUs are returned and gives workflow count distinction, but does not disclose authentication needs, pagination, or response format. Adequate but not exhaustive.

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

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

Three sentences, front-loaded with main action and scope. Every sentence provides useful information 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 no output schema and many sibling tools, the description adequately explains what the tool does and how it relates to others. Could mention response structure or pagination, but is otherwise 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 covers all parameters (100% coverage), but description adds value by explaining the implication of SKU parameter (single vs multiple workflows) and the optional resource group filter.

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 'List all Logic Apps', specifies scope (subscription/resource group), and distinguishes between Consumption and Standard SKUs. It also directs to sibling tool list_workflows for Standard Logic App workflows.

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

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

Provides clear context for usage and directs to list_workflows for Standard Logic Apps' workflows. No explicit when-not usage, but the sibling list and description imply when to use alternatives.

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

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

With no annotations, the description discloses pagination behavior (nextLink, skipToken) and SKU requirement. It does not explicitly state read-only nature, but that is implied. Missing details on rate limits or authorization, but acceptable for a list 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 three sentences, covering purpose, filtering, alternatives, next steps, and pagination. Every sentence adds value with no 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?

Given no output schema, the description covers return of nextLink for pagination and directs to downstream tools for details. This is complete for a list 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 100%, so baseline is 3. The description adds value by explaining pagination (skipToken from nextLink) and reinforcing SKU requirement. This goes beyond the 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 it gets run history for a workflow with optional filtering. It distinguishes from sibling tool 'search_runs' by noting that search_runs is for easier filtering. It also mentions pagination.

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: 'Use search_runs for easier filtering by status/date. After finding a run, use get_run_details and get_run_actions to debug.' It also specifies the requirement of workflowName for Standard SKU.

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. Description implies read-only and authentication but doesn't disclose what happens on failure, rate limits, or side effects. Carries full burden but only partially meets it.

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, no fluff. First sentence states purpose, second provides usage context. 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?

Simple tool with no params. Description adequate but lacks detail about return values (e.g., subscription IDs/names). Since output schema missing, could be more informative.

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?

No parameters; schema coverage 100%. Description adds no param info but none needed. Baseline 4 for zero parameters.

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 verb 'List' and resource 'Azure subscriptions', with scope 'accessible to the authenticated user'. It distinguishes from sibling list_logic_apps by suggesting ordering.

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 says 'Use this first to discover available subscriptions, then use list_logic_apps' – good guidance on sequence, but lacks when-not-to-use or alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral difference between Standard and Consumption SKUs (multiple vs single workflow). However, it does not mention permissions, ordering, or return format, leaving some gaps.

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

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

The description is two sentences with no filler. The first sentence states the core purpose and key behavioral nuance, and the second sentence provides clear usage guidance. Every part is essential.

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 simplicity of the tool and the absence of an output schema, the description adequately covers the essential behavior and usage context. It could mention the expected return structure or prerequisites, but it is sufficient for an 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?

Schema coverage is 100%, so the baseline is 3. The description does not add any additional semantics to the parameters (subscriptionId, resourceGroupName, logicAppName) 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 clearly states the tool lists workflows within a Logic App, differentiates between Standard and Consumption SKUs, and explains its primary use case (discovering workflow names before using other workflow-specific tools). This directly distinguishes it from siblings like list_logic_apps.

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 when to use the tool ('to discover workflow names before calling other workflow-specific tools') and provides context about SKU behavior. It lacks explicit when-not-to-use guidance, but the purpose 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?

Describes that it lists versions with timestamps and the Consumption SKU constraint. No annotations provided, so description carries burden; it is adequate but lacks details on permissions, error handling, or 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?

Two sentences, no waste, front-loaded with key information: action, resource, and SKU limitation.

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 list tool with 4 parameters and no output schema, the description is fairly complete: includes resource type, data returned, and constraint. Missing default ordering or pagination info, but acceptable.

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

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

Schema coverage is 100%, so baseline 3. Description does not add extra meaning beyond schema; e.g., 'top' parameter not explained further.

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 lists all versions of a Consumption Logic App workflow with creation and change times, distinguishing from siblings like list_workflows and get_workflow_version.

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 available for Consumption SKU,' setting a clear usage condition. Could mention alternatives for Standard SKU, but the constraint is 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 covers valid run statuses and the original inputs retry. However, it does not disclose side effects (e.g., whether the original run is modified or a new run is created) or authorization needs.

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 concise sentences: purpose, conditions, prerequisite. No unnecessary words. Front-loaded with key action.

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 5 parameters and no output schema, the description covers core behavior, conditions, and a prerequisite. It lacks details on return value or error cases, but is largely complete for selection and 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 coverage is 100% with descriptions for all parameters. The description adds context for workflowName (required for Standard SKU) but this matches the schema's description. No significant additional 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?

The description clearly states the verb 'Resubmit' and the resource 'workflow run', and specifies the condition 'with the original inputs'. It distinguishes from siblings like 'cancel_run' and 'get_run_details' by mentioning to use 'get_run_details' first.

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 explicit conditions (status Failed, Cancelled, or Succeeded), a SKU-specific requirement (workflowName for Standard), and a prerequisite action (use get_run_details to check status). This helps the agent decide when to use this tool.

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

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

No annotations provided, but the description discloses immediate execution and bypassing of conditions. It does not mention permission requirements, potential errors, or idempotency, but the core behavior is transparent.

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

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

Three sentences, front-loaded with the core purpose, then variant and usage flow. No redundant information; each sentence 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?

The description covers purpose, usage flow, and a conditional requirement. It lacks details on synchronous/asynchronous behavior and error handling, but is adequate for a trigger-fire action without 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?

With 100% schema coverage, the description adds value by clarifying the conditional requirement for workflowName under Standard SKU and suggesting use of get_workflow_triggers for triggerName. This enhances parameter understanding 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 the tool manually fires a trigger to start a run, bypassing schedules. It distinguishes from sibling tools by specifying immediate execution and providing a usage flow with get_workflow_triggers and list_run_history.

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

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

It provides clear usage context: workflowName is required for Standard SKU, and suggests using get_workflow_triggers first. It falls short of explicitly stating when not to use the tool or comparing to alternatives like cancel_run.

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 discloses pagination behavior (nextLink, skipToken) and a conditional requirement (workflowName for Standard SKU). It could mention read-only status, but overall it adds useful behavioral context.

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

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

Three concise sentences with no wasted words. Purpose is front-loaded, and additional details are efficiently provided.

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

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

For a tool with 10 parameters and no output schema, the description covers key aspects: purpose, sibling differentiation, pagination, and a requirement. It doesn't describe return values, but the schema handles parameter details well.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of the friendly parameters (vs. OData syntax) and clarifying skipToken pagination, exceeding 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 clearly states the tool searches run history with friendly parameters, explicitly distinguishing it from list_run_history by mentioning when to use this tool instead.

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

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

It provides specific guidance: workflowName is required for Standard SKU, and recommends using this tool over list_run_history when filtering by criteria. It could explicitly state when not to use, but the implication is 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 provided, so description must carry behavioral disclosure. It mentions 'checks connection status and validates authentication' which implies a read-only check, but does not specify side effects, error behavior, or output format. Lacks detail on network calls or validation steps.

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-loaded with purpose, no unnecessary words. Efficient and clear.

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 test tool with no output schema, the description covers purpose and usage context adequately. Lacks details on return values or failure modes, but these are somewhat inferable.

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% for all three parameters. The description adds no extra meaning beyond the schema. Baseline of 3 applies as per guidelines.

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?

Explicit verb 'test' and resource 'API connection' clearly state what the tool does. Distinguishes from siblings like get_connection_details (retrieval) and create_connection (creation).

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: 'Use this to diagnose connector failures in workflow runs.' Does not explicitly mention when not to use or name alternatives, but the context is sufficient for typical 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?

No annotations provided, so description must fully disclose behavior. It states full replacement but does not mention idempotency, error conditions, permissions needed, or side effects on existing state. For a mutation tool, this is insufficiently transparent.

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

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

Two paragraphs: first states main purpose and replacement behavior, second details SKU specifics. Front-loaded, no redundant sentences. Could be slightly more structured (e.g., bullet points for SKU differences), but effective and 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?

No output schema; description does not mention return value or confirmation of update. Given complexity (7 params, nested objects, SKU variations), missing information about what the tool returns and how to verify success reduces 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?

All 7 parameters have schema descriptions (100% coverage), but the description adds value by clarifying the role of workflowName in Standard SKU, kind defaults, and providing a concrete example for connections. This goes beyond schema descriptions and helps agent usage.

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 the tool updates an existing workflow's definition by replacing the entire definition. It specifies the verb 'update', the resource 'workflow definition', and distinguishes from create or get operations. SKU-specific details further clarify 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?

Provides explicit workflow: use get_workflow_definition first, modify, then update. Recommends get_connector_swagger for connector actions. Notes SKU-specific requirements (workflowName for Standard, connections for Consumption). Lacks explicit when-not-to-use or alternatives, but context is strong.

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?

The description discloses the tool's non-destructive nature (validates without cloning) and checks performed, but with no annotations available, it omits details like authentication needs, rate limits, or how results are returned, leaving gaps for an agent.

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

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

Two clear, front-loaded sentences with zero waste. Every sentence adds value, efficiently conveying purpose and usage.

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 output schema and 8 parameters, the description covers the main purpose and usage but lacks detail on the return value format or error handling, which would be helpful for complete understanding.

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 baseline is 3. The description adds no extra meaning beyond the schema; it does not elaborate on any parameters individually.

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 validates cloning feasibility without performing the clone, distinguishes from sibling clone_workflow by specifying it is a pre-check, and lists what it checks (unsupported operations, connection compatibility).

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 says to use this tool before clone_workflow to identify issues, providing clear usage context. However, it does not mention when not to use this tool or alternative scenarios, missing an explicit exclusion.

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