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

Adds real context beyond the annotations: a GPU charge, sub-minute latency, asynchronous submission returning only a job ID, and the ownership/immutability prerequisites. The annotations already declare destructive=false, idempotent=true, and openWorldHint=true, so the safety profile is largely covered; the description does not discuss polling, notification, or failure modes beyond the schema's own notify_url note.

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?

Front-loaded and dense: cost, speed, and the CFD comparison come first, followed by prerequisites and the return shape. A few fragment sentences and the somewhat redundant "This is inference, not CFD or model training" (already implied by "instead of a full CFD run") cost a point, but nothing is padding.

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 an async, cost-incurring inference submission with an output schema present, the definition covers cost, latency, exclusivity, and prerequisites, which is most of what an agent needs before calling. Missing are explicit notes on job lifecycle (polling vs notify_url) and what the model range boundary means in practice.

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 only 25% across eight parameters, but the description compensates for the two most consequential ones: geometry_artifact_id as an owned geometry-design artifact and model_version as an explicit immutable release (pinning semantics). It says nothing about conditions, project_id, include_fields, or notify_url, so an agent must still lean on the schema for half the surface.

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?

States a specific verb and resource: a fast PhysicsAI estimate of thermal or flow performance, in seconds, instead of a full CFD run. It also explicitly negates adjacent capabilities ("This is inference, not CFD or model training") and states the concrete output ("Returns a job ID"), so an agent can separate it from simulation, meshing, or training tools.

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?

Gives both a positive trigger (quick thermal/flow estimate instead of a full CFD run) and an explicit exclusion ("Not a substitute for a simulation when the user needs a solver result or the design is outside the model's range"). The precondition of an owned geometry-design artifact plus an explicit immutable release is also stated, which is enough to route correctly without opening the schema.

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