evaluate_rules

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

The description discloses several behavioral details beyond the readOnlyHint annotation, including the data source (training_data), refresh schedule (daily at 21:00 UTC), weekend/holiday behavior (uses most recent trading day), and the return values (per-rule triggered, action, indicator values, recommended_weights, weight_changes). It also notes that no FLOW model is needed. No contradiction with the read-only annotation.

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

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

The description is concise and well-structured, covering purpose, distinction, return values, data source, and usage in four tight paragraphs. Every sentence contributes actionable information without redundancy.

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

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

For a tool of this complexity, the description fully covers what it does, when to use it, what it returns, and its data freshness. The output schema already documents the return structure, so no further detail is needed. It also correctly positions this tool relative to forward_test_rules.

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

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

The input schema already fully describes both parameters (portfolio_id as 'Portfolio UUID' and rule_ids with explicit instruction to omit for all active rules). The description adds no additional parameter-specific detail, so the baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Check which portfolio trading rules trigger on TODAY's real market data.' It explicitly distinguishes itself from the sibling tool forward_test_rules by contrasting data sources, making the purpose unmistakable.

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

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

The description provides explicit usage guidance: 'Use this for daily any rules fired? monitoring' and directs users to forward_test_rules for alternative use cases. It also explains the key difference from forward_test_rules in the first paragraph.

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