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

No annotations are provided, so the description carries the full behavioral burden. It lists the summary's contents (a form of output transparency) but omits that it is read-only, account-wide unless profile_id is set, or whether rate limits apply.

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 listing the metrics. No wasted words; appropriately sized.

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 summary with fully documented parameters and no output schema, the description adequately covers return content. It could mention the default time window or that it is account-wide, but the schema supplies those details.

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 fully documents all three parameters. The description adds no parameter semantics beyond what the schema provides; 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 uses a noun phrase but specifies the exact metrics returned (total queries, blocked/allowed counts, blocked percentage, IPv4/IPv6, encrypted queries). It clearly conveys a read-only summary tool, though it lacks a verb and does not differentiate itself from siblings like get_logs.

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

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

No when-to-use guidance, no alternatives, and no prerequisites are stated. The agent is not told when this summary is preferable to get_logs or other 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a persistent mutation but does not say whether the rule takes effect immediately, how allow and deny rules are ordered when they conflict, whether creation requires elevated permissions, or whether the rule is reversible (delete_rule exists but that link is not drawn). For a policy-mutating tool with zero annotation coverage this is a meaningful 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 short sentences, zero filler, with the core action front-loaded and the enum semantics immediately after. Nothing needs trimming.

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 fully documented and self-sufficient for invocation, so the description is adequate for calling the tool. However, for a mutation with no annotations and no output schema, it omits the effect model (immediacy, precedence between allow and deny, interaction with filter categories) that an agent needs to use it correctly in a policy context.

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

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

Schema description coverage is 100% and each parameter already carries its own description, including the kind enum. The description's restatement of kind=allow/deny largely duplicates the schema's own 'allow to permit, deny to block' text, adding no format, constraint, or matching-semantics 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?

The description gives a specific verb+resource+scope: create a custom allow/deny rule for a domain on a profile. It is clearly distinct from create_schedule or delete_rule, but it does not distinguish a 'rule' from the related filter-category siblings (list_filter_categories, set_filter_category), leaving the boundary between those concepts unexplained.

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 second sentence explains what each kind value means, which is parameter guidance rather than usage guidance. There is no statement of when to create a rule versus using set_filter_category, no prerequisites (e.g. profile must exist), and no note about how rules interact with existing policy.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention permissions needed, whether schedule names must be unique, what happens on conflicts, or the return behavior. The single hint about rules/filter categories referencing schedules is useful context but far from sufficient for a mutation 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?

Two sentences, front-loaded with the core action, no redundancy. The second sentence adds scope context efficiently.

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 required-parameter mutation tool with no annotations and no output schema, the description is incomplete. It should state required permissions, prerequisites (e.g., profile existence, timezone format expectations are covered by schema but usage expectations are not), and what the created schedule enables.

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

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

Schema description coverage is 100%, so the schema fully documents all six parameters including formats and examples. The description adds no parameter-level detail beyond implying a profile association, which is already in the schema. Baseline 3 is appropriate 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?

The description states a specific verb+resource: 'Create a time-based schedule on a profile.' It clearly distinguishes from sibling list_schedules and delete_schedule, but does not mention the parent resource ('profile') handling or how it differs from create_rule beyond the 'time-based' qualifier.

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

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

No explicit when-to-use guidance or prerequisites are provided. The second sentence hints at integration with rules/filter categories, which implies usage context, but there is no statement about when this tool should be chosen over create_rule or whether the profile must already exist.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the key trait: the operation is destructive and the rule stops applying immediately. However, it omits permissions/auth requirements, whether the deletion is reversible or the rule can be recreated, and any confirmation semantics for a mutation.

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 zero filler; the destructive warning is front-loaded immediately after the action statement.

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 delete with full schema coverage, the description covers the essential effect (immediate loss of the rule's application) but says nothing about authorization, permanence, or recovery, which matters for a destructive operation with no annotations backing it.

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

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

Schema description coverage is 100% and both parameters are documented in-schema with discovery hints (list_rules, list_profiles). The description adds no parameter-level meaning, 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 (Delete) and resource (custom rule from a profile), which cleanly separates it from siblings like create_rule and list_rules. The scope ('custom rule', 'from a profile') is precise enough that no schema inspection is needed to know what it does.

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

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

No guidance on when to delete versus other options, and no prerequisites or warnings about conditions that should be checked first. The usage is only implied by the verb; the agent gets no routing help beyond the obvious.

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

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

With no annotations, the description carries the full burden, and it does disclose the destructive nature plus a genuine side effect: rules referencing the schedule lose their time window. That cascade detail is valuable behavioral context, though irreversibility, permission requirements, and error behavior remain unstated.

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

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

Two short sentences with no waste; the core action is front-loaded and the destructive consequence follows immediately. Every clause earns its place.

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

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

For a simple two-parameter delete with no output schema, the description covers the action and the key downstream effect on referencing rules. It is nearly complete, missing only confirmation/reversibility semantics and any auth expectations.

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

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

Schema description coverage is 100% and both parameters already document their own discovery tools (list_profiles, list_schedules), so the schema does the heavy lifting. The description adds nothing about parameter syntax or format beyond what the schema provides, which is the baseline case.

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 ('Delete a schedule from a profile'), which is unambiguous and easily separated from siblings like list_schedules or create_schedule by verb alone. It stops short of explicitly naming alternatives or scope limits, so it is clear but not maximally differentiated.

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 the verb: an agent infers this is for removing schedules, but there is no stated when-to-use, when-not-to-use, or named alternative (e.g. delete_rule, list_schedules) to route between. The consequence sentence hints at care but is not guidance on selection.

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

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

With no annotations, the description carries the full behavioral burden; 'Get' implies a read-only operation, which is consistent. It does not disclose whether authentication/scope is required, whether results are cached, or per-account vs per-workspace scoping, but it does clarify the return payload in the absence of an output 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 no filler; the verb and the returned data are immediately clear.

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

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

For a zero-parameter read tool with no output schema, the description adequately enumerates the return content (plan, limits, usage). It is nearly complete, with only auth/scope behavior left unstated.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There are no parameter names or formats that need explaining.

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') and resource ('account plan, limits, current usage'), listing the concrete data returned (max rules, profiles, devices). It is clearly distinct from every sibling, none of which deal with entitlements, though it does not explicitly name any alternative.

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 explicit when-to-use or when-not-to-use guidance. The context of checking plan limits before creating rules or devices is only implied by the returned fields, and no alternatives or prerequisites are mentioned.

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

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

With no annotations, the description carries the full burden, and it does disclose the shape of a returned record (query, action, timestamp) plus a vague recency scope. However, it never pins down what "recent" means, whether results are paginated or ordered, or how the default limit behaves, which matters for a log-listing tool with no output 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?

Two short sentences, front-loaded with the verb and resource, then the return content and use cases. No filler or repetition.

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

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

For a read-only, zero-required-parameter tool with full schema coverage, the description covers purpose, returned fields, and usage intent. The one real gap is the undefined "recent" window, which an agent would want when deciding between this and analytics_summary.

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

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

Schema description coverage is 100% and every parameter (limit, action, profile_id) is documented in the schema itself. The description adds no filter syntax or format detail beyond what the schema already provides, 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?

The description gives a specific verb and resource ("Get recent DNS query logs") and enumerates the record contents (what was queried, allowed or blocked, when). It implicitly separates itself from the aggregate-oriented sibling analytics_summary by being entry-level, but never names or contrasts a 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?

"Useful for reviewing activity or investigating a block" gives two loose scenarios but no when-not guidance, no mention of analytics_summary as the aggregate alternative, and no prerequisites. Usage is implied rather than directed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation but does not disclose permissions, whether the profile is returned in full or partial form, error behavior for unknown IDs, or any other operational trait beyond the basic purpose.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the stated purpose, though its brevity comes at the cost of usage and behavioral detail.

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 with one fully documented required parameter, the description is minimally sufficient to invoke the tool. However, with no annotations and no output schema, it could do more to clarify usage context and expected behavior.

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

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

Schema description coverage is 100%, and the single profile_id parameter is already documented in the schema with a helpful note to use list_profiles for discovery. The description adds no parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and resource ('details of a single profile'), making the operation clear. It implies a contrast with the sibling list_profiles through 'single', but does not explicitly name or differentiate that alternative.

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

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

The description provides no guidance on when to use get_profile versus list_profiles or other siblings. The only routing hint, 'use list_profiles to discover IDs', appears in the parameter schema and addresses ID discovery, not tool selection.

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

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

No annotations are supplied, so the description carries the full burden. The 'Get' verb and the stated return content (code and link) imply a non-mutating read, but nothing is said about auth requirements, whether the account must be enrolled in the program, or what happens when no referral program is active. Minimum viable disclosure for a simple getter.

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 the resource. Every clause earns its place by naming both returned artifacts and the program scope.

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 present, the description does supply the return contents (code and link), which is the key thing an agent needs. It is slightly thin on failure/eligibility behavior, but for a parameterless lookup tool it is close to 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to clarify beyond the schema. No parameter semantics are missing because none exist.

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) plus two named resources (referral code and link) scoped to a named program, so the agent knows exactly what comes back. No sibling tool (profiles, rules, filters, policies, logs, analytics, schedules, devices, entitlements) overlaps with referral functionality, so the boundary is unambiguous.

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

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

There is no explicit when-to-use statement or mention of alternatives, but for a zero-parameter getter with no competing sibling the usage is strongly implied by the name and description. Adequate, but the definition never states the condition under which an agent should call it.

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

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

No annotations are provided, so the description carries the full burden. 'List' strongly implies a non-destructive read and it usefully discloses that protection status is returned, but it says nothing about pagination, result limits, or required permissions for a tool that may expose many devices.

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 with zero filler, front-loading the verb and resource and appending the returned field. Nothing could be removed without losing meaning.

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 returned data (devices and their protection status), and the sole parameter is fully specified in the schema. Only the absence of pagination/volume behavior keeps it from being fully complete for a 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 coverage is 100% and the single profile_id parameter is already fully documented in the schema, including the pointer to list_profiles for discovery. The description adds no format or syntax detail 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 (List), resource (devices), scope (enrolled on a profile), and even the salient returned field (protection status). It is clearly distinguishable in function, though it does not name or contrast any sibling tool such as list_profiles or get_profile.

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 when-to-use guidance, no stated preconditions, and no mention of alternatives. The only routing hint (use list_profiles to discover IDs) lives in the schema, not the description, so the description itself offers no usage direction.

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

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

With no annotations, the description carries the full behavioral burden. The word 'List' implies a read-only operation and the description discloses that enabled status is returned per category, but it does not confirm read-only safety, permissions, or pagination behavior.

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

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

The description is a single efficient sentence with no redundant or filler content. The purpose and return content are front-loaded 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 simple one-parameter read tool with a fully documented schema, the description is nearly complete because it explains the returned data even though no output schema exists. Minor gaps around read-only confirmation and any pagination behavior keep it from being fully exhaustive.

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

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

Schema description coverage is 100%, and the single profile_id parameter is already fully documented in the schema, including guidance to use list_profiles for discovery. The description adds no parameter-level meaning beyond what the schema provides, 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?

The description states a specific verb and resource ('List filter categories') and explains the returned information ('whether each is enabled on a profile'), including concrete examples of categories. It clearly distinguishes itself from the sibling set_filter_category by being a read/list operation rather than a mutation.

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: an agent would use this to inspect which filter categories are currently enabled on a given profile. However, the description does not explicitly say when to use this tool versus alternatives such as set_filter_category or list_rules, and it gives no 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose scope ('all ... on the account'), which implies an account-wide, unfiltered read, but says nothing about pagination, result ordering, required permissions, or rate limits. For a zero-parameter read-only lister the gap is modest, but it is not fully covered.

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

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

A single front-loaded sentence with the resource and scope stated first and clarifying examples appended. There is no filler, hedging, 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?

For a trivial no-param list tool with no output schema, the description conveys what is returned (the set of profiles) and gives examples of what a profile looks like. What is missing is a note on whether results are paginated or how many profiles to expect, which matters slightly more given the absence of an output schema.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate beyond what the empty schema already conveys. Baseline of 4 applies; the description correctly does not waste words on non-existent inputs.

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 ('DNS protection profiles') plus the scope ('on the account'), which is enough to distinguish it from the singular get_profile sibling. The parenthetical examples (Kids, Work, IoT) add useful domain grounding. It stops short of explicitly contrasting itself with get_profile, so it is clear but not maximally differentiated.

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 intent to enumerate profiles is implied by 'List all', and an agent can infer this is the discovery step before get_profile. However, there is no explicit when-to-use guidance, no statement about when to prefer get_profile, and no prerequisites or ordering hints among the 15 siblings.

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

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

No annotations are provided, so the description carries the full disclosure burden. 'List' implies a read-only operation, which is useful, but there is no mention of pagination, ordering, permissions, or how many rules might be returned. Adequate for a low-risk read, but thin.

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 efficient sentence with the resource front-loaded and zero filler. It is well-formed, though terse enough that it borders on under-specification rather than true conciseness.

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 a fully documented schema, the definition covers what the tool returns at a high level ('allow/deny rules'). With no output schema, more detail on the return shape would help, but the gap is minor.

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

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

Schema description coverage is 100% and the single profile_id parameter already documents itself and points to list_profiles for discovery. The description adds no parameter detail beyond the schema, 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?

The description states a specific verb (List) and resource (custom allow/deny rules) scoped to a profile, which clearly separates it from create_rule and delete_rule. It does not explicitly name siblings, but the purpose is unambiguous.

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

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

There is no when-to-use guidance and no alternatives named; the only hint of usage is 'for a profile', which the required profile_id parameter already enforces. An agent gets no exclusions or routing cues.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a non-mutating read, and the example hints at the returned shape, but there is no disclosure of permissions, pagination, whether disabled/inactive schedules are included, or how results are ordered.

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 purpose front-loaded and the example doing real clarifying work rather than padding. Nothing could be removed without losing meaning.

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, no-annotation, no-output-schema list tool, the description supplies purpose and a concrete example of the domain object, which is most of what an agent needs. Gaps remain around result scope (all schedules vs. active only) and volume, but they are minor.

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?

There is a single parameter with 100% schema description coverage, and the schema already documents profile_id and points to list_profiles for discovery. The phrase 'on a profile' loosely corroborates it but adds no format or constraint 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 (List) and resource (time-based schedules) scoped to a profile, and the parenthetical example ('bedtime 21:00-07:00 on weekdays') pins down exactly what a 'schedule' means here, separating it conceptually from list_rules and list_filter_categories. It never explicitly names a sibling or alternative, so it stops short of a 5.

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

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

The description gives no when-to-use guidance, no prerequisites beyond the implied need for a profile, and no mention of the create_schedule/delete_schedule counterparts an agent might confuse this with. The reader must infer the usage context entirely.

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

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

With no annotations, the description carries the full behavioral burden, yet it only states the toggle action. It does not disclose whether changes take effect immediately, whether they are reversible, what permissions are required, or what the response looks like for a mutation.

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 efficient sentence with the action front-loaded and zero waste. It is well-formed but arguably too terse for a mutation tool, which slightly limits its usefulness.

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?

Parameters are fully documented in the schema, and no output schema exists, so the main gap is behavioral. For a mutation tool with no annotations, the description should carry more behavioral context than a single sentence provides, making it only minimally adequate.

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

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

Schema description coverage is 100%, and the schema itself is rich (slug examples plus pointers to list_filter_categories and list_profiles, and the meaning of 'enabled'). The description adds nothing beyond the schema, 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 pair (enable/disable) and resource (filter category on a profile), which is clear and actionable. It does not name or contrast any sibling (e.g., list_filter_categories), so an agent must infer the distinction, keeping it below a 5.

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 explicit when-to-use guidance, no prerequisite or permission context, and no mention of when to prefer this over list_filter_categories or simulate_policy. Usage is only weakly implied by the verb.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does address the most important trait by explicitly stating 'Does not change anything' (side-effect-free), which an agent needs for a policy tool. But it omits permission requirements, rate limits, and whether the evaluation reflects cached vs live rule state.

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 first front-loads what is evaluated and what comes back, the second kills the main ambiguity (mutating vs non-mutating). 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 two-required-parameter, no-output-schema read tool, the description is nearly complete: it conveys purpose, dry-run semantics, and the shape of the answer. It would be stronger with a note on what determines the verdict (profile rules/priorities) or when the simulation is invalid.

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

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

Schema description coverage is 100% and both parameters (domain, profile_id) are documented in the schema, including a pointer to list_profiles for discovery. The description adds no parameter detail beyond the schema, 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 (check/simulate), the exact resource (profile policy for a given domain), and even previews the result shape (allowed, blocked, why). It is clearly a dry-run evaluation rather than a listing or mutation tool, so an agent can distinguish it from siblings like list_rules or get_logs without opening schemas.

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

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

The 'right now' phrasing implies this is a real-time, point-in-time evaluation, which is useful context. However, it never says when to prefer this over alternatives (e.g. inspecting rules directly) or what prerequisites exist, so usage is only implied.

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