Synchronize BeamNG documentation

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

The description adds useful context with 'bounded' and 'official pages', but it does not disclose operational behaviors such as network dependency, potential delays, or whether the refresh replaces or merges existing data. Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) already indicate it's a non-read-only, side-effecting operation, so the description is consistent but not highly informative.

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 description is a single, concise sentence that front-loads the main action and object. There is no redundant wording, and it adheres to an efficient structure without losing essential intended meaning.

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?

The description is too sparse for a tool with three optional parameters and no output schema. It omits parameter explanations, usage context (e.g., when to run a sync before searching), and effects on the existing local index. An agent would lack critical details to invoke it correctly and confidently.

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?

With schema description coverage at 0%, the description should explain parameters like 'force', 'category', and 'maxPages'. It does not mention any of them. While the names are somewhat self-explanatory, their precise semantics (e.g., what 'force' forces, how 'category' filters, what 'maxPages' limits) remain ambiguous, requiring the agent to infer or probe.

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 what the tool does: 'Refresh the bounded local index from official BeamNG modding pages.' It uses a specific verb ('refresh'), identifies the resource ('bounded local index'), and mentions the source ('official BeamNG modding pages'). This distinguishes it from sibling search/get tools, which query rather than update the index.

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?

No guidance is provided on when to use this tool versus alternatives like beamng_docs_search or beamng_docs_get. The description merely states the action without explaining prerequisites, triggers (e.g., stale index), or scenarios where this tool is preferred.

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