source_labonneboite

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

No annotations exist, so description bears full burden. It discloses the tool fetches data from a hidden job market, returns JobPostings with a prefix, and requires specific env vars. However, it does not address side effects (e.g., rate limits, data freshness, or error handling), leaving some behavioral gaps.

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 with purpose, but includes a multi-sentence note about environment setup and scope. Could be slightly more concise, but each sentence provides necessary context.

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?

Given the tool's complexity (3 parameters, output schema exists), the description covers prerequisites, data source, and result format. It adequately informs an agent about when to use the tool, though some details like geographic limitations are implied.

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 coverage is 100%, so baseline is 3. The description reiterates parameter meanings (ROME code, INSEE commune) but does not add significant extra detail beyond the schema. The distance default is already in the schema.

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 clearly states it fetches companies likely to hire from La Bonne Boîte, specifying it surfaces companies likely to recruit for a given ROME code and commune, even without formal job offers. It distinctly describes the tool's purpose and differentiates it from siblings by its unique data source.

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?

Provides clear context: requires environment variables FRANCE_TRAVAIL_ID and FRANCE_TRAVAIL_SECRET, and scope api_labonneboitev1 with partner subscription. It advises live verification before production use. However, it does not explicitly exclude alternatives or mention when not to use.

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