get_model_info

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

With no annotations, the description carries the full disclosure burden and delivers: return shape (plain say_to_user line, target, specs with Numerical/Categorical types and allowed categories) and the critical presentation constraint — 'do NOT surface algorithm / R² / log-target (or the words SHAP, log-target, R²) to the user.' It also explains that include_internal=true exposes those hidden raw fields for agent-side reasoning, exactly the non-obvious behavioral nuance agents need.

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 purpose and output shape are front-loaded in the first two sentences, and the presentation rule and include_internal flag each earn their place. The only redundancy is 'Use it to understand what inputs a model expects' partly repeating the earlier 'everything you need to build a predict/explain call' framing.

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?

An output schema exists, so return-value detail is offloaded; the description covers what the schema cannot express — when to call, what to lead with, and words never to surface to the user. For a two-parameter informational tool with no annotations, nothing an agent needs to invoke it correctly is missing.

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%, so the description must compensate. It adds real semantics for include_internal — default false hides internal fields, true returns raw fields for reasoning. model_id is only implied as 'a specific model' rather than explicitly tied to the parameter, but the added detail about specs, types, and allowed categories gives parameter-level meaning the bare schema lacks.

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 opening sentence 'Get detailed information about a specific model' uses a specific verb-resource pair and scopes it to a single model, distinguishing it from sibling list_models. It further orients the agent by naming predict/explain as downstream consumers, telling the agent this tool is the metadata prerequisite rather than the prediction itself.

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?

Explicitly instructs 'Use it to understand what inputs a model expects' and frames the result as 'everything you need to build a predict/explain call,' giving a concrete trigger condition. It does not name when-not-to-use alternatives (e.g., 'for a list of models, use list_models'), which keeps it from a 5.

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