lbb_models

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

readOnlyHint=true is consistent with the description's purely read-oriented actions (no contradiction), and the description adds useful behavior beyond annotations: bounded training examples at an optional signal split, one pinned snapshot, activity defaulting to the current month. It omits permissions, pagination/limit behavior, and the 'compact/standard/full' detail implications, so it is additive but not rich.

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 whole definition is a single dense run-on paragraph mixing all four actions, with the activity sentence ending in a long parenthetical feature list. It is not front-loaded per action and forces the reader to re-parse to figure out which clauses belong to shadow_eval versus the dataset actions.

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 7-parameter, four-action, nested-body tool with no output schema, the description does sketch what activity returns (calls, items, tokens, cost per feature and model, by day and by graph), which is valuable. It still leaves limit semantics, detail-level behavior, and per-action parameter applicability unstated, so it is adequate but not 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?

With only 43% schema coverage, the description does compensate partially: it explains that body is the API ShadowEvalRequest payload and that split_seq selects an optional signal split, neither documented in the schema. But it says nothing about limit or the detail enum's effect, and the action-to-parameter mapping (which params apply to which action) is left to inference.

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 all four actions and gives each a concrete verb+resource: shadow_eval compares retrieval configurations over a pinned snapshot, the dataset actions return training examples, activity reports model usage. However, it never distinguishes this tool from close siblings such as lbb_evals or lbb_model_choice, so an agent cannot tell from the description alone why it should pick this tool for eval work rather than one of those.

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 / when-not-to-use guidance and no alternative named. The only routing signal is implicit in the action names themselves ('shadow_eval', 'suggest_dataset', 'extractor_dataset', 'activity'), which the schema already exposes as an enum, so the description adds almost nothing about selection.

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