get_jsx

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

With no annotations provided, the description carries the full disclosure burden. It does reveal meaningful behavioral detail — that output is JSX, that node descendants are included, and that tailwind is the default format with inline-styles as an option. It does not, however, describe any size/recursion limits or error behavior for large node trees, which would strengthen transparency.

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 tightly written sentences with the core action front-loaded and no filler. Every phrase earns its place, and the format options are stated compactly.

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?

With no output schema, the description responsibly indicates the return type (JSX code representation), and the tool is simple enough that the main gap is moderate. The biggest omission is usage differentiation against export_code and write_html, plus a hint of the return's scope for large trees, which keeps this at a solid but not complete level.

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 100%, so the baseline is 3. The description adds marginal value by reinforcing that tailwind is the default format and that descendant nodes are included, which maps to the format and nodeId parameters respectively, but it does not go beyond what the schema already documents.

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 uses a specific verb-resource pair: 'Get the JSX code representation of a node and its descendants,' clarifying both the action and the scope. It also names the two output formats. It does not explicitly contrast itself with overlapping siblings like export_code or write_html, so it stops short of full differentiation.

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 given on when to select this tool over alternatives such as export_code, write_html, or get_computed_styles, several of which are plausible competitors in the sibling list. There is no stated context, precondition, or exclusion, so an agent must infer usage purely from the name.

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