koru-shield

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the content of the result set, but says nothing about read-only nature, required permissions/entitlements, aggregation behavior, or whether the window is inclusive; for an analytics tool with zero annotation coverage this leaves real gaps.

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

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

A single dense sentence with no filler and the metric list front-loaded. It is a fragment rather than a complete sentence, which slightly hurts readability but costs no tokens.

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 compensates well by enumerating the returned metrics. Parameters are fully covered by the schema. What remains missing is usage context relative to siblings, so it is not fully complete.

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

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

Schema description coverage is 100% and all three parameters (from, to, profile_id) are documented in-schema, including the 24h default and the profile scoping rule. The description adds no parameter-level meaning, 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?

States a specific resource (DNS activity) and enumerates the exact metrics returned (total queries, blocked vs allowed, blocked percentage, IPv4/IPv6, encrypted queries), which distinguishes it from log/detail siblings like get_logs. It never uses an explicit verb ('returns'/'summarizes'), so it stops short of 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 when-to-use guidance. Nothing tells the agent to pick this over get_logs for raw events, or that it is the aggregate counterpoint to detailed log retrieval, and no prerequisites or exclusions 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose permission/entitlement requirements, whether a new rule overrides existing ones or how precedence works, whether it takes effect immediately, or what happens if a rule for the domain already exists.

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

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

Two tight sentences with the what/where front-loaded and the enum semantics second. Zero filler or restated boilerplate.

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?

A mutation tool with no annotations and no output schema needs to carry its own safety/permission context. The description covers the create action and enum semantics adequately but omits precedence, idempotency/duplicate behavior, and authorization requirements.

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 four parameters (profile_id, kind, domain, note) are already documented in the schema, including the enum meaning. The description's restatement of kind=allow/deny adds nothing beyond the schema's own enum description, and the optional note parameter is never mentioned.

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 (Create) and resource (custom allow/deny rule) plus scope (for a domain on a profile). An agent can immediately distinguish it from delete_rule, list_rules, and create_schedule 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?

The second sentence explains how to use the kind enum (deny to block, allow to permit), which is invocation guidance rather than tool-selection guidance. It never says when to reach for create_rule instead of simulate_policy to test a rule first, nor when-not to use it (e.g. duplicates, managed domains).

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 not say whether the schedule takes effect immediately, what happens on duplicate names, what permissions are needed, or what identifier is returned for later reference by rules — all relevant for a mutation tool with six required parameters.

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 the action and followed by the domain rationale; nothing is padded or 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?

Purpose and domain context are covered and the schema fully documents inputs, but with no annotations and no output schema the description omits key facts an agent needs: whether a schedule ID is returned (needed to wire it into rules), activation timing, and duplicate-name 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%, with every parameter (timezone, days, start, end, name, profile_id) documented including formats and examples, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond that, which matches the baseline of 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 ('Create a time-based schedule on a profile') and the second sentence explains what a schedule is for, which implicitly separates it from the sibling create_rule tool that would consume it. It does not explicitly name what it is not, so it falls short of full sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives such as create_rule, delete_schedule, or list_schedules, and no prerequisites stated. The mention that rules and filter categories can reference schedules describes the concept, not when to invoke this tool.

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

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

With no annotations, the description carries the safety burden and does disclose an important behavioral trait: the operation is destructive and the rule stops applying immediately. It stops short of stating irreversibility, required permissions, or failure modes, but the core warning is present.

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

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

Two short sentences, front-loaded with the action and immediately followed by the destructive effect. Every sentence earns its place.

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

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

For a simple two-parameter mutation with full schema coverage and no output schema, the description is largely complete: it states the action and the key destructive consequence. It could be strengthened with a note on irreversibility or permissions, but the essential context is present.

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

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

Schema description coverage is 100%, so the schema already documents both parameters and even points to list_rules and list_profiles for ID discovery. The description adds no parameter-level detail beyond that, making the baseline 3 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 states a specific verb and resource: 'Delete a custom rule from a profile.' It clearly distinguishes this operation from siblings like create_rule and list_rules without needing schema inspection.

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 delete action and the phrase 'from a profile,' but the description gives no explicit when-to-use guidance, no exclusions, and no reference to alternatives or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the key consequence: deleting cascades so referencing rules lose their time window. That is genuinely useful, non-obvious context. It stops short of stating irreversibility, required permissions, or whether deletion is blocked when referenced.

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 followed immediately by the destructive consequence. Nothing is 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 simple two-parameter delete with no output schema, the description covers purpose and the main side effect, and the schema covers ID discovery. It omits confirmation semantics and auth requirements, but the essentials for correct invocation are present.

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

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

Schema coverage is 100% and both parameters (profile_id, schedule_id) are documented in the schema with discovery hints, so the description need not repeat them. It adds no extra meaning beyond the schema, making the baseline 3 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 ('Delete a schedule from a profile'), which unambiguously separates it from sibling mutations like delete_rule and from create_schedule. The scope (schedule within a profile) is 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives. The only routing help comes from the schema descriptions ('use list_schedules to discover IDs'), not the description text itself.

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?

No annotations are provided, so the description carries the full burden. It does disclose the shape of returned data (query, allowed/blocked, timestamp) and implies recency ordering via 'recent', which is real value given there is no output schema, but it says nothing about pagination, retention window, or permissions for a list tool that caps results at 100.

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 clauses with the resource and returned fields front-loaded and the use case trailing. No filler, no repetition of the 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 read-only list tool with no annotations and no output schema, the description covers purpose, returned fields, and a use case. Remaining gaps (ordering guarantee, retention, pagination semantics of limit) are minor but not trivial for a log-inspection 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 all three parameters (limit, action, profile_id) are already documented in the schema, including the action enum. The description's 'allowed or blocked' phrasing only echoes the enum and adds no filtering syntax or default behavior 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?

States a specific verb and resource ('Get recent DNS query logs') and enumerates what the entries contain (query, action, timestamp). It reads clearly against siblings, none of which retrieve logs, though it does not name any 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 an implied use context, but there is no when-not-to-use guidance and no pointer to analytics_summary for aggregate questions. The agent must infer the boundary between raw log retrieval and the analytics sibling on its own.

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, yet it only restates the purpose. 'Get' implies a safe read, but the description does not say what a 'detail' includes, what happens if the profile_id is unknown, or whether any permissions are required.

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, front-loaded sentence with zero waste. It is arguably under-specified rather than overly long, 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?

For a single-parameter read tool with a fully documented schema and no output schema, the description is minimally adequate, but it omits any hint at the return shape ('details' is vague) and offers no usage context relative to its many siblings.

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 a single well-documented parameter, so the schema does the heavy lifting. The description adds nothing beyond the schema, which is the appropriate baseline 3 for full-coverage schemas.

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 (details of a single profile), and the word 'single' implicitly distinguishes it from list_profiles. It does not explicitly name the list_profiles alternative, but an agent can still tell the fetch-one vs list-many distinction from the phrasing.

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, and no mention of the sibling list_profiles it pairs with. The only routing hint ('use list_profiles to discover IDs') lives in the schema, not the description.

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?

With no annotations, the description carries the full behavioral burden. It does convey that results are per-profile and include protection status, but says nothing about read-only safety, pagination/result limits, ordering, or auth/permission requirements for a per-profile enumeration.

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 and scope front-loaded and no filler. It is efficient, though it is terse enough that it omits useful context that would have earned 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 one-parameter read list this is minimally adequate: the parameter is fully described and the return subject is stated, but with no annotations and no output schema the agent gets no confirmation that the call is a safe read or any hint about result volume or 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%, so the single profile_id parameter (including its pattern and the list_profiles discovery hint) is fully documented in the schema. The description only implies profile scoping and adds no format or constraint detail, 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 ('List') plus resource ('devices') plus scope ('enrolled on a profile') and even the payload ('their protection status'). It is unambiguous against siblings like list_profiles/list_rules, though it never names a sibling to sharpen 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 description states only what the tool returns; it gives no when-to-use context, no prerequisites beyond the implied profile_id, and no mention of alternatives if the agent wanted a different view of devices. Only the schema hint ('use list_profiles to discover IDs') provides any routing guidance, and that lives in the structured field.

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 read-only, non-mutating operation and the description does disclose the shape of the return (per-category enabled flag), which is useful. It does not state permission requirements, whether the enabled state is profile-scoped or inherited, or any 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 that names the resource, gives concrete examples, and states exactly what is returned. 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 one fully documented parameter and no output schema, the description compensates by explaining the return in prose (categories plus their enabled state). For a simple read tool this is largely sufficient, though it stops short of noting inheritance behavior or how the result relates to set_filter_category.

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 parameter profile_id is documented in the schema, including the pointer to list_profiles for discovery. The description adds nothing about the parameter, 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 filter categories') and clarifies the returned payload: the categories and whether each is enabled on a profile. The parenthetical examples (adult content, gambling, social media) make the resource unambiguous and clearly separate it from the sibling set_filter_category.

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 call this to inspect a profile's content-filter state. However, there is no explicit when-to-use guidance, no mention that set_filter_category is the counterpart for changing these values, and no stated prerequisites beyond the profile_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?

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?

With no annotations, the description carries the full behavioral burden. It implies a read-only listing but says nothing about permissions, pagination, ordering, or whether rules from other profiles leak in — all relevant 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 front-loaded sentence with zero filler. It is appropriately sized for a one-parameter list tool, though it lacks any secondary sentence about scope or output.

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

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

No output schema and no annotations, so the description is the only source of behavioral context — and it provides none about return shape or pagination. For a simple list tool this is a visible gap, not a fatal one.

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 required profile_id is fully documented, including the discovery hint. The description adds no format or constraint 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?

States a specific verb (List) and resource (custom allow/deny rules) scoped to a profile, which distinguishes it cleanly from the create_rule and delete_rule siblings. It does not name those siblings explicitly, 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?

No when-to-use context, no prerequisites, and no alternatives are mentioned in the description. The only routing hint ('use list_profiles to discover IDs') lives in the parameter schema, not the description.

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 behavioral burden. The verb 'List' implies a safe read, but nothing is said about permission requirements, result ordering, pagination, or behavior when a profile has no schedules. The example clarifies data shape only, not 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?

A single front-loaded sentence with the resource scope first and a genuinely illustrative example second. No padding, no restated boilerplate.

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-parameter read tool with no output schema and no annotations, the description covers the core purpose but leaves the agent guessing about result format and scope of returned schedules. It is minimal but not misleading, which is the minimum-viable level.

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

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

Schema description coverage is 100% for the single parameter (profile_id), including a pattern and a discovery hint, so the schema already does the work. The description adds nothing beyond what the schema states, which is the expected baseline for a fully documented single parameter.

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

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

The description names a specific verb and resource ('List time-based schedules on a profile') and the parenthetical example ('bedtime 21:00-07:00 on weekdays') makes the resource concept concrete and distinct from list_rules or list_devices. It stops short of explicitly naming a sibling or exclusion, 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?

There is no when-to-use guidance, no mention of prerequisites, and no alternative named (e.g. create_schedule/delete_schedule for mutation). The only routing hint, 'use list_profiles to discover IDs', lives in the input schema rather than the description, so the description itself provides essentially 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, and it does not say whether the change is idempotent, reversible, permission-gated, or what happens to existing rules. The toggle semantics are only implied by the verb, leaving mutation behavior largely undisclosed.

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 affected resource come first and nothing is 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 simple three-required-parameter mutation with full schema coverage and no output schema, the description is minimally sufficient, but it leaves mutation behavior and prerequisite lookups to the schema rather than stating them.

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 already documents all three parameters including slug examples and the boolean meaning, so the description adds no parameter detail. 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 pair ('enable or disable') and the resource ('a filter category on a profile'), so the operation is unambiguous. It does not, however, distinguish this from sibling tools or explain how it relates to list_filter_categories, which the schema cites.

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 offers no guidance on when to use this versus alternatives, no prerequisites, and no exclusions. The only routing hints (list_filter_categories, list_profiles) live in the schema, not the description.

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 correctly discloses that the operation is non-mutating and reports allowed/blocked/why, which is meaningful. However it omits auth/permission requirements, rate limits, or how the verdict is derived, leaving gaps for a no-annotation tool.

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

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

Two short sentences, front-loaded with the core purpose and followed by the key non-mutation guarantee. Nothing is wasted and there is no redundancy.

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

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

With no output schema and no annotations, the description responsibly names what is returned (allowed, blocked, why) and confirms the call is side-effect free. That covers the essentials for a two-parameter read-style tool; only permission/edge-case behavior is 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?

Schema description coverage is 100%, so both parameters (domain, profile_id) are already well documented in the schema, including the hint to use list_profiles for IDs. The description adds no parameter-level 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?

The description uses a specific verb ('Check') on a specific resource ('profile policy for a domain') and even states the outcome shape (allowed, blocked, why). It is clearly distinguishable from mutation siblings like create_rule or delete_rule, though it doesn't name an alternative 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?

'Check what the profile policy would do for a domain right now' clearly frames this as a dry-run/preview, and 'Does not change anything' signals when to prefer it over the mutating rule tools. No explicit when-not or named alternative is given, but the intent is unambiguous.

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