provider_model_override

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

Annotations only state readOnlyHint=false, so the description does useful work by disclosing that the operation stamps provenance as 'operator_override' — a durable, auditable side effect an agent should know about. It still omits what exactly is mutated (capability flags? model metadata?), whether the override persists or is per-call, and any permission or auth requirement expected of an 'operator'.

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 sentences with the purpose stated first and no filler or repetition. It is tight, but the brevity comes partly at the cost of substance rather than being purely efficient.

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 mutating tool with zero annotation coverage beyond readOnlyHint=false, no output schema, and an undocumented nested 'override' object, the description is far too thin. An agent cannot determine the override's accepted fields, the effect on subsequent model calls, or how to recover/undo 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 0% for 3 parameters, and the description supplies no parameter information at all. Most critically, the 'override' object — the actual payload of the tool — has no documented shape or expected fields, and providerId/modelId are never explained, so an agent has no basis for constructing a valid call.

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 conveys that this is an operator-level override affecting reasoning capability, which is more than a restatement of the name, but it never states a clean verb+resource (e.g. 'sets the reasoning capability override for a provider model') and never distinguishes itself from siblings like provider_save or provider_probe. An agent can guess the domain but not the exact effect.

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?

'when upstream metadata is absent' is a genuine, if narrow, usage condition, and 'Advanced operator' signals this is not a routine path. However, no alternative tool is named for the normal case (presumably provider_save/provider_refresh), and no explicit when-not or precedence guidance is given, so the routing is left implicit.

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