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

With no annotations, the description carries the full behavioral burden even though this is a read-only lookup. It discloses the data source (official INSEE Sirene registry), the fields returned, the 'current' nature of the status, and the paid-per-call cost via x402 USDC, which is meaningful behavioral context beyond a bare tool name.

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 dense sentences front-load the purpose, scope, source, and use-case, then add the pricing detail. No filler or repetition exists, and the key differentiator (cheaper preview of full 360) appears immediately after the function summary.

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 simple single-parameter lookup with no output schema, the description covers what the tool does, what data comes back, where the data comes from, when to use it, and the cost model. It is missing exact retry/error/format nuancesholistics, but the absence is minor given the tool's simplicity and the explicit data source and preview positioning.

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 provides only a generic required string 'q' with 0% description coverage, so the description must compensate. It does so by stating that q accepts 'SIREN or name', which is the essential semantic needed to invoke the tool. It stops short of specifying formats such as SIREN digit length or exact-name matching behavior, but it gives enough for a basic correct 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 states a specific operation and resource: a 'Lite overview of a French company by SIREN or name' covering legal identity, activity code, headcount bracket, and administrative status. It clearly distinguishes this from the full 360 profile by calling itself the 'cheaper preview', so an agent can tell it apart from fr_entreprise-360.

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?

It explicitly positions the tool as a pre-purchase confirmation step: 'meant to let an agent confirm it has the right company before paying for depth.' This gives a clear context for use and implies the full 360 profile is the deeper alternative, though it does not list exclusions or other sibling alternatives explicitly.

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