lsl_migration_guidance

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

The annotations already establish a read-only, idempotent, non-destructive, closed-world operation. "No automatic source rewriting" adds a useful capability limitation beyond those annotations by clarifying that the tool provides guidance rather than transformed code, but filtering and not-found behavior remain undisclosed.

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 short sentences front-load the content scope and then state the key limitation. There is no filler or unnecessary repetition.

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 guidance read with no required parameters and an output schema, the stated scope and no-rewriting limit make a basic unfiltered call viable. The undocumented filters and unstated migration direction and sibling relationship prevent confident targeted invocation and selection.

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?

Neither topic nor symbol is explicitly explained despite 0% schema description coverage. The listed difference categories indirectly suggest possible topics and "per-API" hints at symbol lookup, but valid topic values, filter interaction, and symbol format are left unstated.

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 gives a concrete review task and scope: per-API counterparts plus event, timer, table, numeric, and conversion differences. It does not state the source and target languages or otherwise distinguish itself from slua_migration_guidance, so sibling differentiation remains weak.

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 supplies a clear use case—reviewing migration mappings and semantic differences—and an explicit boundary that it does not perform automatic source rewriting. It does not explain when to prefer lsl_get_guidance, lsl_lookup_symbol, or the SLua migration tool, leaving alternative selection inferential.

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