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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds only the raw endpoint path, with no mention that results are paginated (skip/limit), that the list reflects instance-specific configuration, or how many items typically return. For a catalog-lookup tool with a nested filter param, that is thin 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?

A single tight sentence with the resource stated first and the endpoint as a supporting parenthetical. No filler, though the endpoint alone doesn't earn much extra signal for an agent that already has tool metadata.

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?

There is no output schema, so the description should say something about the shape of results (a list of action type identifiers/names with paging metadata), and it doesn't. Combined with no mention of pagination behavior or the relationship to datto_edr_run_response, the definition is adequate but leaves real gaps for a 5-param paginated list endpoint.

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

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

Schema description coverage is 100%, so all five parameters (skip, limit, order, where, fields) are already documented with examples and operator lists. The description adds nothing about them, so baseline 3 applies — the schema carries the full parameter burden.

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

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

States a specific verb (List) and resource (response/action types) plus the backing endpoint GET /api/ActionTypes, so an agent knows exactly what comes back. It doesn't explicitly differentiate itself from siblings like datto_edr_api_models or datto_edr_run_response, but the resource noun is distinctive enough that confusion is unlikely.

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

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

No when-to-use guidance, no exclusions, and no pointers to alternatives. The description doesn't say this is a reference/lookup call typically made before datto_edr_run_response to discover a valid action type, which is the main reason an agent would call it. Usage is only implied by the resource name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by saying results show reachability and agent mapping, but it does not mention pagination behavior or response shape beyond those two fields.

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 tight sentences with no wasted words. It is front-loaded with the core action and resource, then adds the optional scoping and return-value context.

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

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

For a read-only list tool with no required parameters, a fully described schema, and no output schema, the description covers the core purpose and the most important returned fields. It could be stronger by mentioning pagination or the broader filtering model, but those are already detailed in the schema.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the input schema. The description only highlights target_group_id as an optional filter and does not add syntax or meaning beyond the schema for ip, where, fields, limit, skip, order, hostname, or accessible.

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

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

The description states a specific verb and resource: list discovered host addresses, with the backing endpoint GET /api/Addresses. It also clarifies the optional target-group scoping and the key returned information, but does not explicitly distinguish this from sibling list tools such as datto_edr_agents_list.

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

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

Usage is implied by the resource being listed and the optional target_group_id filter. The description does not say when to choose this over datto_edr_agents_list or other sibling list tools, nor does it state any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that filters are identical to datto_edr_agents_list, which is genuinely useful behavioral context, but says nothing about the response shape or whether unpaginated totals are computed server-side.

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 short sentences, front-loaded with the action and endpoint, followed by the practical use case. Nothing is redundant or padded.

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

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

For an 8-parameter, zero-required count tool with a nested filter object and no output schema, the definition covers what it does and how filters relate to the sibling list. The one gap is that it never states what the return looks like (a total/count field), which matters slightly more given no output schema exists.

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 each parameter carries its own description, including the nested LoopBack `where` operator list, so the schema does the heavy lifting. The description adds only the meta-claim that the filter set matches agents_list, not per-parameter meaning.

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

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

States a specific verb (count) and resource (agents) plus the exact endpoint, and explicitly anchors filter semantics to the sibling datto_edr_agents_list. An agent can distinguish this from the list/get siblings without opening any schema.

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

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

Gives a concrete use case ("how many agents are offline" questions) and points at datto_edr_agents_list as the filter-equivalent for record retrieval. It stops short of an explicit when-not rule (e.g. "use agents_list when you need the records themselves"), but the routing signal 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the backing endpoint (GET /api/Agents/{id}), which is helpful for debugging but conveys nothing about auth scope, 404 behavior, or result contents.

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

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

One sentence, front-loaded with the verb and resource, with the endpoint kept as a compact parenthetical. Nothing to trim and nothing wasted.

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

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

For a single-record read with full schema coverage and read-only annotations, this is nearly sufficient. The remaining gap is minor: no output schema exists, so a hint about what an agent object contains would be the only useful addition.

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

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

Only one parameter and schema description coverage is 100% ('Object id (GUID)'), so the schema already carries the semantics. The description's 'by id' adds no format or constraint detail beyond it; baseline 3 applies.

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

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

Specific verb ('Get one') plus resource ('Datto EDR agent') plus the keying parameter ('by id'), so an agent knows exactly what it retrieves. It does not explicitly name the sibling it contrasts with (datto_edr_agents_list), but the singular-vs-list distinction is unmistakable.

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

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

Usage is only implied: use this when you already have an agent id, otherwise use datto_edr_agents_list. There is no explicit when-to-use, prerequisite, or exclusion statement, and no mention of what happens when the id is unknown.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond them: results are paged via limit/skip, and 'where' filters are AND-combined with the first-class filters. It does not describe default page size or total-count behavior, but that is minor given the annotations.

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

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

Three tight sentences, front-loaded with the verb/resource before the filtering strategy and pagination note. Slight redundancy in re-listing filter dimensions already present in the schema, but nothing wasteful.

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 12-parameter, nested-filter list tool with no output schema and existing annotations, the description covers the essentials: what is searched, how to filter beyond the fixed set, and how pagination works. It stops short of noting response shape or that 'fields' keeps payloads small (the schema covers that), which is acceptable here.

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 earns above that by explaining the intended layering of the 12 params (dedicated filters vs. the 'where' escape hatch) and by naming example properties (OS, version, isolation state) that are not in the schema. Pagination semantics of limit/skip are also tied together conceptually.

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

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

States a specific verb and resource ('List or search Datto EDR endpoint agents') and even names the underlying endpoint (GET /api/Agents). It is clearly a collection-level read, distinguishable in spirit from datto_edr_agents_get, though it never names that sibling explicitly to make the split airtight.

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

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

Gives concrete routing guidance for filtering: use the first-class filters for hostname/IP/state/heartbeat, and fall back to 'where' for other properties after verifying field names via datto_edr_api_models {"model":"Agents"}. It does not state when to prefer datto_edr_agents_get or datto_edr_agents_count over this tool, leaving that to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only, external-source nature is covered. The description adds that results are enriched/joined views rather than raw alerts, which is meaningful context, but says nothing about result volume, paging behavior, or whether filters are combined with other constraints.

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

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

Two tight sentences, front-loaded with what the tool returns and the endpoint, followed by practical filtering hints. No filler or redundancy.

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

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

With no output schema, the description does enough by stating what the records contain (alert + host + file/rule context) and how to narrow and trim responses. A brief note on pagination totals or the default result window would make it fully self-sufficient.

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

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

Schema description coverage is 100%, including operator lists, limits and nextSkip semantics, so the schema carries the parameter burden. The description only echoes where/fields with brief examples that the schema already provides, adding little beyond 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?

Names a specific verb and resource ('List enriched alert records') and pins it to GET /api/AlertDetails, adding that records join alert, host and file/rule context. That enrichment detail implicitly separates it from plain datto_edr_alerts_list, but the sibling is never named, so the differentiation is inferred rather than stated.

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

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

Offers per-parameter advice ('use where to filter by alert id or hostname', 'fields to keep response small') but gives no when-to-use-this-vs-alerts_list guidance and no prerequisites or exclusions. Usage is implied by the data shape rather than explained.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the endpoint path and the important behavioral point that filters are shared with the list tool, but says nothing about the response shape (bare integer vs object) or how archive filters affect the total.

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

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

A single front-loaded sentence with no filler; the core operation comes first and the endpoint is a useful parenthetical. It could have spent one more clause on the return value without becoming bloated.

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

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

With five parameters (including a nested where object), no annotations explaining returns, and no output schema, the description should state what comes back (a count integer) and whether archive_table/include_archived change the total. Those omissions are survivable but leave a gap for a counting tool.

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

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

Schema description coverage is 100%, so each of the five parameters is already documented in detail, including LoopBack operators and archive semantics. The description adds no parameter-level meaning beyond the pointer to the list tool's filters, so the baseline of 3 applies.

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

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

States a specific verb (count) and resource (alerts) and anchors it to an existing sibling (datto_edr_alerts_list) plus the underlying endpoint. An agent can immediately tell this returns a total rather than records.

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 reference to datto_edr_alerts_list establishes clear context: use the same filter set but obtain a count. It does not explicitly say 'prefer this over list when you only need a total', so the choice is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the description's confirmation of the GET endpoint is consistent with them. It adds no behavioral context beyond that, such as what happens when the id is not found or how archive_table changes the lookup path — though that second point is at least covered in the schema.

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

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

A single front-loaded sentence with the resource and lookup key first and the endpoint as supporting detail; nothing is wasted. It is terse to the point of omitting any usage or error context, which keeps it just short of a 5.

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

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

For a two-parameter read-only fetch, the description plus a fully documented schema and readOnly/openWorld annotations give an agent enough to call it correctly. There is no output schema, but since this is a single-record fetch by id the description does not need to restate the return shape to be adequate.

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

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

Schema description coverage is 100%, with both id (GUID) and archive_table (archive lookup flag) documented in the schema, so the baseline is 3. The description's endpoint path reinforces that id is a path parameter but contributes no additional meaning about the archive_table toggle or id format.

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

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

States a specific verb ('Get one') and resource ('Datto EDR alert') scoped by id, plus the underlying endpoint GET /api/Alerts/{id}, which makes the id semantics unambiguous. It never names datto_edr_alerts_list or datto_edr_alert_details_list, so the distinction from those siblings is left implicit.

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

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

Usage is implied — retrieve a single alert when you already have its id — but there is no explicit when-to-use/when-not and no routing to the list or details siblings. An agent can infer the case, but nothing in the text prevents it choosing this tool when it only has a filter rather than an id.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior beyond that: newest-first ordering, the live-vs-archive distinction, and the 30-day archive threshold. It does not discuss pagination behavior, rate limits, or response shape.

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 dense sentences with no filler, and the core purpose and endpoint are front-loaded. Every sentence contributes operational detail about filtering, field lookup, or archive access.

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

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

For a 9-parameter, fully optional list tool with complete schema descriptions and read-only annotations, the description covers the non-obvious points an agent needs: ordering, date filtering, generic "where" filtering, model lookup, and archive handling. Return values and pagination are either obvious or covered by the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful guidance beyond the schema by explaining that "where" can filter on any property, pointing to datto_edr_api_models for field names, and clarifying when to set archive_table.

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

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

The description states a specific verb and resource: "List Datto EDR alerts," along with the underlying endpoint and default ordering. The list semantics clearly separate it from siblings such as datto_edr_alerts_get and datto_edr_alerts_count, even though those tools are not named.

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 explains how to use the main filters: date range, archived state, and arbitrary properties through "where." It also gives a clear condition for archive_table: alerts older than 30 days. It does not explicitly say when to choose this over alerts_get, alerts_count, or raw_request, so it stops short of full alternative guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's main added value is disclosing the data source (/explorer/swagger.json) and the two behavioral modes (omit = enumerate all; pass = expand one model). It does not mention response size or cost of enumerating all models, a minor gap.

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

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

Two tight sentences with no filler; the core action and its data source come first, and the purpose statement follows immediately. Every clause carries 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 one-optional-parameter, read-only discovery tool with no output schema, the description covers what the tool returns in both modes (model list vs. paths and properties) and why an agent would call it. Only the shape/size of the returned model listing is left implicit.

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 already documents the model parameter with an example. The description nonetheless reinforces the semantic branch: omit the parameter to list all models, pass it to get paths/properties for one. That adds slight meaning beyond the schema, above the baseline 3.

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

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

States a specific verb and resource ('List the API models this Datto EDR instance exposes') plus the two operating modes (list-all vs. single-model detail). This clearly separates it from every sibling, which are concrete resource endpoints (agents_list, alerts_list, etc.), since this one is a discovery/meta tool.

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

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

Explicitly names the when-to-use case: 'find filterable field names before building a "where" filter.' It also clarifies mode selection via the optional model argument. It does not name an alternative tool (e.g., datto_edr_raw_request) or state when not to use it, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds only the endpoint path; it says nothing about pagination behavior (how to page with nextSkip), result size, ordering defaults, or rate limits. That is a thin addition over what the annotations and schema already convey.

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

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

A single front-loaded sentence with zero filler. It is efficient but borders on under-specified given the tool's filtering and pagination surface.

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?

Six optional parameters, a nested where filter, and no output schema; the schema carries most of the load, but the description offers nothing on how results are shaped (items vs. nextSkip) or sensible filtering patterns. Adequate but with clear gaps for an agent paginating a large audit log.

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 skip/limit/order/where/fields/user_id all documented including examples and operator lists. The description adds no parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (list) and resource (user activity / audit log entries), and names the backing endpoint, which distinguishes it from sibling list tools like agents_list or alerts_list. It is clear what it returns, though the description is essentially the name restated plus an endpoint.

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

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

No when-to-use guidance, no mention of when to prefer this over datto_edr_raw_request or datto_edr_api_models, and no hint that pagination via skip/limit is the intended workflow. The agent is left to infer usage from the schema alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds only the raw HTTP endpoint (GET /api/extensions/{id}), which is documentation of the wire call rather than behavior such as not-found handling or what fields an extension record contains.

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

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

A single front-loaded sentence with zero padding; the identifying action and resource come first and the endpoint acts as useful confirmation.

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

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

For a one-parameter read tool with full schema coverage and annotations carrying the safety profile, the definition is nearly sufficient. The only real gap is how to source the id, which a slightly richer description could close.

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 single parameter is documented as 'Object id (GUID)' with a minLength constraint. The description's 'by id' matches but adds no format or sourcing detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get one extension by id') and the singular 'one' implicitly distinguishes it from datto_edr_extensions_list. The parenthetical endpoint reinforces the resource, though no sibling is named explicitly.

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

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

There is no guidance on when to use this versus datto_edr_extensions_list, nor on how an agent should obtain a valid id (e.g., from the list endpoint). The reader must infer all routing from the tool name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by mapping the tool to the concrete HTTP endpoint and clarifying the domain meaning of 'extensions' (collection extensions and response actions) plus the downstream dependency on run_response. It doesn't touch on result volume or paging behavior, which keeps it from a 5.

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

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

Two compact sentences with zero filler; the identity and endpoint come first, then the downstream consumer. Every clause carries information an agent would otherwise have to infer.

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

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

For a read-only list tool with no output schema, the description covers what the resource is, the endpoint, and why an agent would call it. The only meaningful omission is that results are paginated (the skip/limit/nextSkip contract lives solely in the schema), which an agent might miss when assembling a multi-page workflow.

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

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

Schema description coverage is 100%, so every parameter including the nested LoopBack 'where' filter and the pagination fields is already documented in the schema. The description adds no parameter-level meaning beyond restating the 'Host Isolation' example that also appears in the name field, so the baseline 3 applies.

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

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

Specific verb plus resource ('List Datto EDR extensions'), backed by the underlying endpoint (GET /api/extensions) and concrete examples of what an extension is ('Host Isolation', 'Host Isolation Restore'). It also distinguishes itself from the sibling datto_edr_extensions_get by being the collection lister.

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 closing sentence establishes the workflow: extension ids/names 'feed datto_edr_run_response', which tells an agent exactly when to reach for this tool. It stops short of an explicit when-not statement or naming extensions_get as the single-record alternative, so it's clear context rather than full routing guidance.

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

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

Annotations already cover safety (readOnlyHint) and openness (openWorldHint). The description adds genuinely non-obvious runtime behavior: the endpoint is resolved from this instance's /explorer/swagger.json, and a missing endpoint produces an error listing related models. That failure-mode disclosure is valuable context an agent would not otherwise have.

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. The second sentence is denser but earns its place by covering endpoint resolution and the fallback. Slightly more technical detail than an agent needs in the headline, but no wasted text.

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

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

With full schema coverage, no required params, and no output schema, the main gaps are return shape and pagination semantics, which the schema already handles via skip/limit. The description fills the remaining critical gap — what happens when the endpoint doesn't exist — making it nearly complete for a read-only list call.

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% for all five parameters (skip, limit, order, where, fields), including operator lists and examples, so the schema carries the semantics. The description adds nothing about parameters; baseline 3 applies.

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

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

A clear verb+resource ("List configured integrations") with concrete examples (RMM, PSA, RocketCyber) that make the resource tangible. It is distinguishable from sibling list tools like extensions_list or agents_list by naming the domain, though it doesn't explicitly contrast with them.

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

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

Usage is implied by the resource name, and there is a helpful fallback hint: if the endpoint is missing, the returned error points at related models to query with datto_edr_raw_request. However, it never says when to prefer this over datto_edr_raw_request directly or how it differs from adjacent list 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?

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true) by explaining exactly what connectivity is lost versus preserved ('keeps talking to Datto EDR but loses all other network access') and how isolation ends. It also discloses the dry-run behavior of omitting confirm, which the annotations cannot express.

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 short sentences, front-loaded with the impact warning, then the effect, then the precondition. No filler and nothing repeated from structured fields.

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

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

For a destructive, open-world action with no output schema, the description covers impact, blast radius, supported platforms, and the confirmation gate, which is nearly everything an agent needs. It stops short of stating permission requirements or how long isolation persists before an agent should verify restoration.

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

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

Schema description coverage is 100%, so the schema already explains target, target_group_id, and the confirm gate. The description reinforces the confirm requirement and cross-references datto_edr_target_groups_list for the group id, but adds no new syntax or format detail 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?

States a specific verb and resource ('Network-isolate one host') plus the mechanism used ('Host Isolation' response extension), so the agent knows exactly what will happen. The scope ('one host') and the 'until restored' clause implicitly distinguish it from datto_edr_restore_host among the siblings.

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

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

Clear context for use: it is flagged HIGH-IMPACT and gated on 'confirm: true', which tells the agent this is a deliberate, escalation-level action. It hints at the reversal path ('until restored') but never explicitly names datto_edr_restore_host as the alternative to use when un-isolating, so there is no hard exclusion rule.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the underlying GET /api/jobs endpoint, which helps an agent understand it is a thin read pass-through, but it says nothing about paging behavior, default result volume, or what a job record contains.

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 short sentences, resource and endpoint front-loaded, no filler. The second sentence is largely redundant with the schema's state example, which keeps it just short of a 5.

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

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

Six optional parameters, nested where-filter, no output schema, and only two annotations. The description never explains what a background job represents, how paging results should be consumed, or that there is no corresponding jobs_get sibling (so detail must come from fields/where) — leaving real gaps for an agent planning a call.

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 skip/limit/order/where/fields all well documented including the nextSkip paging convention and LoopBack operators. The description's only parameter contribution is echoing the state="active" example already present in the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('List background jobs') and anchors it to the concrete endpoint GET /api/jobs, which is more precise than a generic 'list' label. It does not explicitly differentiate itself from adjacent list tools such as datto_edr_tasks_list or datto_edr_audit_log_list, so the agent must infer the boundary.

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 sentence 'Pass state "active" for running jobs' implies the common polling use case, but it is a parameter hint rather than a when-to-use rule. There is no statement of when to prefer this over datto_edr_raw_request or the other *_list siblings, and no prerequisites or exclusions.

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

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

Adds real behavioral context beyond annotations: the endpoint is resolved dynamically from this instance's /explorer/swagger.json, and a missing endpoint produces an error listing related models. That dynamic-resolution detail is information an agent cannot get from readOnlyHint/openWorldHint alone.

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 primary action and followed by the failure path. Every sentence carries actionable information with no filler.

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

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

No output schema exists, yet the description adequately conveys that a single location record is returned and what happens on failure. A brief note on the shape of the returned location object would close the remaining gap.

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

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

Only one parameter, fully documented in the schema as an object GUID at 100% coverage. The description repeats "by id" without adding format, source, or validation guidance, so it neither helps nor hurts beyond the schema 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?

States a specific verb and resource ("Get one Datto EDR location by id") and the singular scope implicitly separates it from datto_edr_locations_list. It never names the list sibling explicitly, so differentiation is inferred rather than declared.

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

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

Gives clear context for use (fetching a single location by id) and an actionable fallback: if the endpoint is absent, use datto_edr_raw_request with a related model from the error. It stops short of explicitly telling the agent to use datto_edr_locations_list for enumeration instead.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important runtime behavior: the endpoint is resolved from /explorer/swagger.json, and a missing endpoint produces an error listing related models for datto_edr_raw_request. It does not cover rate limits or response structure, but it adds meaningful operational 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?

The description is three sentences, front-loaded with the core list operation and then the filtering and fallback details. Every sentence contributes actionable information with no redundant restatement of the tool name.

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

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

For a list endpoint with no output schema, the description covers the key dynamic behavior around endpoint lookup and fallback. It does not explain the return shape or pagination behavior, though the skip parameter description already mentions nextSkip from the previous page.

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

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

Schema coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds semantic guidance by explaining that organization filtering happens through "where" and that datto_edr_api_models should be used to discover the correct field names, which is useful 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 uses a specific verb and resource: "List Datto EDR locations," and clarifies that locations are "sites inside organizations," distinguishing them from organizations and from the singular locations_get sibling. An agent can identify the operation without opening the schema.

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

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

It gives concrete usage context for filtering by organization via the "where" parameter and points to datto_edr_api_models for field-name discovery. It also names datto_edr_raw_request as the fallback when the endpoint is missing, though it does not explicitly contrast this list tool with locations_get or locations count 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the return shape (tool names + descriptions), the domain-scoping of results, and the non-prerequisite nature. Minor gap: it doesn't say whether the listing is filtered by permissions or whether repeated calls are cached/idempotent.

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 short sentences, zero filler, and the most decision-relevant claim (not a prerequisite) is placed last as a clarifying punch rather than buried. Nothing to cut.

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 does state what is returned (names and descriptions), and annotations cover the safety profile, so an agent has enough to call it correctly. It could be slightly more complete on whether results include parameter hints or just labels, but that is a minor gap for a discovery helper.

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 domain enum already enumerates and explains all seven values in detail. The description adds only that the result is scoped to the selected domain, which is marginal beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb (Discover) and resource (Datto EDR tools) scoped by domain, and explicitly clarifies it returns tool names and descriptions rather than performing any EDR action. That separates it cleanly from the ~35 sibling operation tools without opening any schema.

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

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

Explicitly tells the agent when-not-to-use it as a gate: 'All tools are callable at any time — this is a help/discovery aid, not a prerequisite.' This directly preempts the common failure mode of an agent wasting a call to 'unlock' other tools, and implicitly routes the agent to direct sibling calls when it already knows the operation.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond annotations: the endpoint is resolved from the instance's swagger.json, and missing endpoints produce an error listing related models. It does not describe the return shape, but no output schema exists and the added endpoint-resolution behavior is valuable.

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

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

Two sentences with no wasted words. The primary purpose is front-loaded, and the endpoint-resolution/fallback sentence is compact and operationally useful.

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

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

For a simple single-resource read tool with complete schema coverage, annotations covering safety, and no output schema, the description supplies everything an agent needs: purpose, key parameter meaning, and fallback behavior if the endpoint is unavailable.

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 single parameter is documented as an object id (GUID). The description only restates that lookup is by id, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Get one Datto EDR organization') and the lookup key ('by id'). This clearly distinguishes it from the sibling list tool datto_edr_organizations_list without requiring the schema.

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

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

The description makes clear this is the single-organization-by-id lookup, implicitly contrasted with the list sibling. It also explains a fallback path when the endpoint is missing: use datto_edr_raw_request with related models from the error. It does not explicitly say when not to use it, but the context 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine non-obvious behavior: the endpoint is resolved dynamically from the instance's swagger.json and failure surfaces related models. It stops short of describing pagination or return shape.

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 filler. The core action is front-loaded and the operational fallback follows immediately after, in the order an agent would need it.

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 should ideally state what comes back (a list of organization objects plus nextSkip for pagination). It covers the discovery/failure path well and the schema covers all five parameters, but the return shape is left implicit.

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 skip/limit/order/where/fields all documented including LoopBack operators and the nextSkip convention. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('List Datto EDR organizations') and clarifies the resource with '(tenants/customers)', which disambiguates the domain term. It does not explicitly contrast with the sibling datto_edr_organizations_get, but the list/get naming makes the distinction inferable.

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

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

Gives clear context for use and an explicit fallback path: if the endpoint is absent from /explorer/swagger.json, the error points to related models queryable via datto_edr_raw_request. It does not state exclusions (e.g., when to prefer organizations_get for a single tenant), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds material behavior: the token is injected automatically, object values in the query are JSON-encoded, and credential/token models are blocked server-side. It stops short of covering rate limits or any error/response shape, so not a 5.

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

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

Four short sentences, front-loaded with the purpose, then the routing rule, then the request mechanics, then the safety exclusion. Every sentence carries distinct information with no repetition of the schema or annotations.

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

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

For an open-ended proxy tool with no output schema, the description covers invocation mechanics (URL shape, auth, encoding, blocked models) well. The main remaining gap is what an arbitrary GET returns or how errors surface, which is inherently hard for a generic endpoint but would still help.

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, but the description genuinely adds meaning beyond the schema: it explains the JSON-encoding rule for object values and shows concrete forms for a LoopBack filter and a count path. That is semantic guidance the schema's example alone does not convey.

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

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

The description opens with a specific verb-plus-resource: a read-only escape hatch that issues GET requests to Datto EDR API endpoints not covered by typed tools. That framing immediately distinguishes it from every typed sibling (agents_list, alerts_get, etc.) and states the scope of what it targets.

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

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

It gives explicit routing guidance with 'Prefer typed tools', which tells the agent to try a typed sibling first, and it names a hard exclusion ('Credential and token models are refused'). That is both when-to-use and when-not-to-use guidance.

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

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

Annotations already declare destructive/non-idempotent/open-world, so the safety profile is covered. The description adds real value beyond that: a '⚠ HIGH-IMPACT' severity framing and the fact that execution runs an EDR response extension on the endpoint, plus the confirm gate. It stops short of describing what happens to the host's connectivity or whether the action is reversible.

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

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

Two short sentences with the impact warning front-loaded and the execution precondition last. Nothing is wasted and the agent can act on it immediately.

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 3-param mutation tool with no output schema and full annotation coverage, the description covers purpose, severity and the confirmation gate. It could say more about the effect on the target host (e.g., network access restored, agent reconnect timing), but nothing essential is missing.

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

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

Schema coverage is 100%, so all three parameters including the confirm dry-run behavior are already fully documented. The description only restates the confirm requirement, adding no syntax or format detail beyond the schema — baseline 3 is appropriate.

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

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

States a specific verb+resource ('Remove network isolation from one host') and names the mechanism ('Host Isolation Restore' response extension). This clearly distinguishes it from the inverse sibling datto_edr_isolate_host and from the generic datto_edr_run_response.

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

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

Usage is implied — restore isolation on a host that was previously isolated — but the description never names datto_edr_isolate_host as the counterpart or says when to prefer this over calling datto_edr_run_response directly with the extension. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the concrete endpoint mapping, which is mildly useful for API-aware agents, but says nothing about behavior on a missing/invalid id or what a rule object contains.

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

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

One short sentence, front-loaded with the verb and resource, with the endpoint in parentheses as secondary detail. 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 one-parameter read tool with annotations covering safety and a fully described schema, this is nearly sufficient; the rule object's shape is presumably documented by the sibling rules_list. A brief note on not-found behavior would make it 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?

Single required parameter with 100% schema coverage, where the schema already documents it as an object GUID. The description's 'by id' adds nothing beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get one detection rule by id') and includes the underlying endpoint, making the single-item fetch unambiguous against the sibling datto_edr_rules_list. It stops short of 5 only because it doesn't explicitly contrast itself with that sibling.

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

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

Usage is implied by 'by id' and the GET path – the agent can infer this is for retrieving a single already-known rule, with rules_list as the natural alternative. No explicit when-to-use or prerequisite statement is given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the underlying API path (GET /api/rules), which is minor context; nothing is said about pagination behavior or result ordering beyond what the schema hints.

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

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

A single short sentence with no waste, and the resource is front-loaded. It is arguably under-specified rather than concise, but nothing is redundant.

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

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

The schema is rich and carries all six parameters, and annotations cover the read-only/open-world profile, so the description doesn't need to repeat them. However, for a filterable list tool with a nested LoopBack where object, the description could have noted pagination flow and typical use, which it does not.

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 skip/limit/order/where/fields and name all documented in the schema itself, including the LoopBack operator list. The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the work.

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

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

The description states a specific verb (List) and a specific resource (Datto EDR detection rules), so the agent knows exactly what comes back. It does not explicitly distinguish the tool from the sibling datto_edr_rules_get, though the list-vs-get naming implies the difference.

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

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

There is no guidance on when to use this tool versus datto_edr_rules_get, datto_edr_api_models, or any other sibling. The agent has to infer from the name and schema that this is the paginated collection endpoint.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent behavior, so the safety profile is covered. The description adds real value beyond that: the explicit HIGH-IMPACT framing and the dry-run semantics ('without confirm, returns the request it would send') tell the agent exactly what happens when the flag is omitted. It omits permission requirements and failure behavior, keeping it from a 5.

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

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

The warning is front-loaded and the endpoint, identification method, and confirm gate follow in one compact block with no filler. It is dense but not bloated; a slightly clearer separation between the impact warning and the operational guidance would make it a 5.

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

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

For a destructive, open-world 6-parameter mutation with no output schema, the description covers impact level, the confirm safety gate, and how to locate the required target_group_id — the essentials for calling it correctly. It does not describe what a successful execution returns or how errors surface, a minor gap given there is no output schema to fall back on.

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

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

Schema description coverage is 100%, so every parameter — including the confirm dry-run semantics and the extension_id vs extension_name precedence — is already documented in the schema. The description reinforces the id/name choice but adds no syntax, format, or constraint detail beyond what structured fields supply. Baseline 3 applies.

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

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

States a specific verb and resource ('Run a response extension'), gives concrete examples (kill process, isolate, collect evidence), names the endpoint, and explains how the extension is identified. It stops short of distinguishing itself from sibling datto_edr_isolate_host, which it actually lists 'isolate' as an example of, so an agent could hesitate between the two.

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 a genuine prerequisite (target_group_id must come from datto_edr_target_groups_list) and the confirm:true gate, which is clear usage context. However, it gives no when-not guidance and does not route the agent away from overlapping siblings like datto_edr_isolate_host or datto_edr_scan_host, leaving the selection decision implicit.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, but the description adds real value beyond them: the HEADLINE high-impact warning, the fact that it consumes endpoint resources, the dry-run/confirm gating behavior, and the task-id return value. It doesn't cover permission requirements or whether a scan can be cancelled, which keeps it from a 5.

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

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

Four short clauses with the most decision-relevant warning ('⚠ HIGH-IMPACT') front-loaded, followed by the mechanism, the confirmation gate, and the handoff tool. No filler and nothing repeated from the schema verbatim beyond what's needed for emphasis.

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

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

For a destructive, non-idempotent, nested-parameter tool with no output schema, the description supplies the essentials: impact level, endpoint side effects, confirmation semantics, and the returned task id. It leaves out authorization prerequisites and whether repeated scans are safe or throttled, which would matter for a high-impact 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 target, confirm, target_group_id, and even the options sub-flags with their defaults. The description only reinforces the confirm parameter and says nothing about how the options collection affects scan scope or runtime — baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Start a forensic scan of one host') plus the underlying endpoint (POST /api/targets/scan). This cleanly distinguishes it from sibling read tools like datto_edr_scans_list and datto_edr_scans_get, which retrieve scan records rather than initiating one.

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?

Establishes context (one host, forensic scan) and an explicit gate: 'Requires confirm: true; without it, returns the request it would send.' It also names the follow-up tool (datto_edr_tasks_get) for polling results. It stops short of naming alternatives such as datto_edr_isolate_host or explaining when a scan is not warranted, so it doesn't reach 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the raw endpoint path (GET /api/scans/{id}) and says nothing about not-found behavior, error shapes, or what a scan object contains—minimal value beyond the structured fields.

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

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

A single short sentence with zero waste and the key qualifier ('by id') front-loaded. It is arguably too terse, but nothing is padded or buried.

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

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

For a one-parameter read with full schema coverage and annotations, this is close to adequate, but with no output schema the description could say what a scan record includes or how it differs from scan_host / scans_list results.

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 the single 'id' parameter, and the schema already states it is a GUID. The description's 'by id' merely restates the parameter name, so baseline 3 applies.

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

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

The description gives a specific verb and resource ('Get one scan by id') and implicitly distinguishes itself from the sibling datto_edr_scans_list by retrieving a single record. It does not explicitly name the list sibling, but the singular 'one scan' makes the distinction clear.

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

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

Usage is only implied: 'by id' suggests you must already have a scan id, which typically comes from datto_edr_scans_list, but that alternative is never named and no exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the endpoint path and the optional scoping; it says nothing about pagination semantics, result volume, or how skip/limit interact across pages, which are the behaviors that actually matter 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?

A single sentence with zero filler, front-loaded with the verb and resource. Nothing in it is redundant or buried.

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

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

For a 6-parameter tool with a nested where filter and no output schema, the description is thin: it does not characterize the returned scan records, pagination flow, or default ordering. The rich schema compensates for most parameter-level gaps, but the description itself does the minimum.

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%, including detailed LoopBack where/order semantics and pagination guidance, so the schema carries the parameter burden. The description only echoes the target_group_id filter, adding no syntax or behavior beyond the structured fields — baseline 3 applies.

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

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

The description gives a specific verb and resource ('List Datto EDR scans') plus the backing endpoint (GET /api/scans), which lets an agent separate it from the singular datto_edr_scans_get sibling. It stops short of naming that sibling outright, so the differentiation is implied rather than explicit.

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?

'optionally for one target group' hints at when the filter matters, but there is no statement of when to prefer this over datto_edr_scans_get, datto_edr_target_groups_list, or datto_edr_navigate. Usage is implied by the name and endpoint rather than explained.

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 key behavioral trait — this is an offline configuration inspection that makes no network call — is stated outright and goes beyond the readOnlyHint/openWorldHint annotations, which only imply it. What is missing is any hint about the shape or scope of the returned domain list, but with no output schema that gap is minor.

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

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

Two sentences, zero padding, with the primary behavior front-loaded and the disambiguation second. Every clause carries information an agent needs.

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

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

For a zero-parameter, non-destructive status probe with annotations covering the safety profile, the description says enough to call it correctly and interpret the intent. The only shortfall is that it does not indicate what the returned domain list represents or how a failure looks, which matters slightly since no output schema exists.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The text correctly implies the tool is parameterless by describing an unconditional check.

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

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

States a specific verb (check whether credentials are configured) plus a concrete secondary output (list available domains), which is more than a restatement of the name. It also distinguishes itself from the nearest sibling by naming datto_edr_test_connection explicitly.

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

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

Gives both the exclusion ("Does not call the API") and the alternative plus the condition that selects it ("use datto_edr_test_connection for a live check"). An agent can route between the two tools without opening either schema.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the underlying GET endpoint, but does not disclose error behavior such as missing-id/404 handling or what a returned target group contains.

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

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

A single sentence with the key scope and endpoint front-loaded. There is no wasted text.

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

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

For a simple read-only lookup with one fully documented parameter and annotations covering the safety profile, the definition is essentially complete. The only minor gap is that no output schema exists and the description does not describe the returned target-group shape.

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 already documents the single required 'id' parameter as a GUID. The description only reinforces that retrieval is by id and adds no syntax or formatting detail 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?

States a specific verb and resource: get one target group by id. The word 'one' implicitly distinguishes it from the sibling datto_edr_target_groups_list, though it does not name that sibling explicitly.

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

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

Usage is implied by 'by id' – a caller should use this when they have a specific target-group GUID. There is no explicit guidance on when to prefer the list sibling or what to do if the id is unknown.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful domain context about what target groups contain, but says nothing about pagination (schema covers it), result size, or what the returned records look like.

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

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

Two tight sentences with zero padding: the first states the action and endpoint, the second front-loads the domain meaning and the reason an agent would call it.

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?

There is no output schema, and the description only tells the agent that ids are the payload of interest; it does not describe other returned fields or pagination behavior, though the schema covers paging inputs. Adequate for a filtered list tool, with a small gap on return shape.

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% — name, skip, limit, order, where, and fields are all documented in the schema, including nextSkip semantics and supported LoopBack operators. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('List Datto EDR target groups') plus the underlying endpoint (GET /api/targets), and explains what the resource is (hosts that scans and response actions run against). It does not explicitly contrast itself with the sibling datto_edr_target_groups_get, so the list-vs-single distinction is only implied by the names.

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

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

Gives concrete downstream context: the returned ids are needed by datto_edr_scan_host and the response tools, which tells an agent when to call this first. No explicit when-not or alternative-path guidance (e.g. when to use target_groups_get by id instead) is given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description contributes the useful behavioral framing that results are per-host records of a scan or response, but says nothing about response shape, pagination via nextSkip, or result size limits.

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

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

A single front-loaded sentence naming the action, the resource, the endpoint, and a clarifying example. Nothing is redundant and nothing pads it.

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

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

The tool has six parameters, a nested filter object, and no output schema, yet the description never characterizes the returned per-host item structure or how paging completes. Given no output schema exists, the description should carry more of the return-shape burden than it does.

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%, including detailed LoopBack syntax for where/order and pagination notes for skip/limit, so the schema carries the parameter burden. The description adds no parameter-level guidance beyond what the schema already says; only task_id's role is reinforced by context.

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

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

States a specific verb (List) and resource (per-host items of a user task) and even cites the underlying endpoint GET /api/userTaskItems, plus a concrete example of what the items represent. It implicitly separates itself from task-level siblings like datto_edr_tasks_get, but never names them, so the differentiation is inferred rather than stated.

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

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

Usage is only implied: an agent must infer that this is the tool to call after obtaining a task_id from datto_edr_tasks_list when per-host detail is needed. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. jobs_list for per-host job status).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond that by disclosing the returned payload ('status, progress and message'), which matters because there is no output schema, and by tying it to an initiating operation.

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

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

Two tight sentences: the operation and endpoint come first, the usage cue second. No filler, nothing redundant with the schema.

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

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

For a single-parameter read tool with annotations and no output schema, this is nearly complete: it says what is fetched, what comes back, and why you'd call it. A note on where the task id originates (e.g. from scans_list or run_response) would close the last gap.

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

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

Schema description coverage is 100% with the id field documented as 'Object id (GUID)', so the baseline is 3. The description only reinforces that the id identifies a user task, without adding format, source, or how to obtain the id.

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

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

States a specific verb and resource ('Get one user task by id') and even cites the underlying endpoint GET /api/usertasks/{id}. The singular 'one' implicitly distinguishes it from datto_edr_tasks_list and datto_edr_task_items_list, though those siblings are never named.

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?

'Use it to follow a scan or response started by this server' gives a concrete trigger condition for calling the tool. It stops short of naming alternatives or stating when not to use it (e.g. use tasks_list to discover ids first), so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered by structured data. The description still earns credit by disclosing the default sort order (newest first) and the underlying endpoint, which are behavioral facts an agent would otherwise have to guess; it omits rate limits and pagination mechanics, but the schema's skip/nextSkip text covers the latter.

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 short sentences, zero filler, with the core action and the newest-first ordering front-loaded. The endpoint and the status tip are tacked on without padding the text.

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

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

For a read-only, fully documented eight-parameter list tool with no output schema, the definition covers what it returns at a category level and how to interpret the main filter. It stops short of describing the response shape or how archived tasks differ when include_archived is set, but nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already carries the heavy lifting for all eight parameters. The description contributes one genuine semantic addition — that status "Active" corresponds to running tasks — but adds nothing about type, where, order, or fields beyond what those parameter descriptions already say.

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

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

States a specific verb and resource ("List user tasks") and clarifies scope with a parenthetical listing the task kinds surfaced (scans, responses, enumerations), plus the backing endpoint GET /api/usertasks. It reads clearly as the collection counterpart to datto_edr_tasks_get and datto_edr_task_items_list, though it never names those siblings to draw the boundary explicitly.

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 one usage hint — use status "Active" for running tasks — tells the agent how to get live work, which is a real operational cue. Beyond that there is no guidance on when to prefer this over datto_edr_scans_list, datto_edr_jobs_list, or datto_edr_task_items_list, nor any stated preconditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by naming the underlying endpoint and the shape of the result (instance host and API version), which is useful beyond the annotations. It doesn't mention auth failure behavior, but that's minor for a read-only probe.

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

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

One sentence, front-loaded with the action and immediately followed by the endpoint and return values. No filler.

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

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

With no output schema, the description helpfully names the return values (host and API version). It's nearly complete for a parameterless probe; only auth-failure or timeout behavior is unmentioned, which is a minor gap given the read-only annotations.

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?

Zero parameters, so the baseline is 4. The description correctly implies no input is needed via the explicit endpoint reference, consistent with the empty schema.

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

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

States a specific verb (test), the resources (connection and token), the exact endpoint (GET /api/Version), and what is returned. This is clearly distinguishable from siblings like datto_edr_status or datto_edr_agents_list.

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 purpose implies usage — verifying credentials before other calls — but the description never states when to use this versus datto_edr_status or datto_edr_raw_request, nor any prerequisites (e.g., that credentials must be configured first). Context is implied rather than explicit.

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