rpa_policy

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

With no annotations, the description carries the full disclosure burden. It does useful work by enumerating the six data categories the tool exposes, which effectively doubles as a return-value preview since there is no output schema. However, it never states that the operation is read-only/side-effect-free, nor whether results are tenant-scoped, whether it requires admin privileges, or whether the snapshot is live or cached.

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 that leads with the purpose and then front-loads the concrete payload via a compact colon-delimited list, so nothing is buried. Every enumerated item is informative rather than filler. Minor cost: the enumeration dominates the sentence, leaving the core purpose compressed into the opening clause.

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, no-output-schema inspection tool, the description supplies exactly the missing piece: what data comes back. That covers the main completeness gap. It could go further by noting read-only semantics and access prerequisites, but for a simple snapshot tool this is close to sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate at the argument level; baseline for a parameterless tool is 4. The enumerated field list adds orientation without conflicting with the empty schema.

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

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

The description pairs a specific verb (查看/view) with a concrete resource (当前企业护栏/current enterprise guardrails) and then enumerates the exact contents: app whitelist, approval list, per-app concurrency cap, idempotency window, running task count, and rejection stats. An agent can tell this is a read-only policy/inspection tool. It stops short of explicitly contrasting itself with the neighboring rpa_list_apps, which also surfaces whitelist-style app data, so sibling differentiation is only implicit.

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

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

Usage is implied: an agent should call this when it needs to know the tenant's guardrail configuration or current load before starting a job. There is no explicit when-to-use statement, no when-not-to-use, and no naming of alternatives such as rpa_list_apps or rpa_app_params for narrower lookups. The intent is inferable from the field list but left to the agent.

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