conduyt_create_dashboard

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

No annotations exist, so the description carries the full disclosure burden. It explains the board-filter model but omits key behavior: the created dashboard appears to have no tiles parameter, so it likely starts empty, and nothing is said about permissions (beyond schema text on isShared), reversibility, or limits on tile/filter counts.

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?

A single front-loaded sentence with a colon-delimited clarification; every clause (tiles, report types, shared filter set) adds semantic content rather than repeating the title.

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 annotations, no output schema, and a nested filters object, the description should say more about the creation lifecycle – notably whether the dashboard is created empty and must be populated with tile calls, and who can see it. It explains the concept but not the operational consequences.

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 50%; the description adds conceptual meaning for the filters object ("one set of filters for the whole board"), though the schema's own nested description already says filters apply to EVERY tile. The name, isShared, and description parameters get no elaboration in the description.

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?

States a specific verb and resource ("Create a dashboard") and then defines the concept: a board of tiles, each a saved report shown as KPI/chart/table/pivot. That is clear enough to distinguish it from conduyt_create_report or conduyt_update_dashboard, but the description never names those siblings or contrasts scope with them.

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?

There is no when-to-use, when-not-to-use, or prerequisite guidance. An agent is not told that the referenced saved reports must already exist, that tiles are attached later via conduyt_add_dashboard_tile, or how this differs from conduyt_create_report.

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