tigergraph__drop_graph

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

Annotations already mark this as destructive, but the description goes much further by specifying that schema, vertices, edges, queries, and loading jobs are all deleted, that the operation is permanent and cannot be undone, and that extra caution is required. It also advises backing up production graphs. This gives the agent a clear and accurate risk profile.

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 well-structured with clear headings: purpose, use cases, quick start, warning, and tips. It front-loads the critical information and then expands helpfully without rambling. Every section adds operational value, especially the bolded permanence warning.

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 destructive two-parameter tool with no output schema, the description covers the action, the risk, the prerequisites, and the safer alternative. It also tells the agent to list graphs first to confirm the name. The optional profile parameter is sufficiently covered by the schema, so nothing essential is missing.

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 applies. The description adds a Quick Start JSON example showing graph_name and a warning to double-check its value, but it does not add substantial new semantics about the parameters themselves. The profile parameter is fully explained in the schema already.

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 opens with a specific verb+resource: 'Drop (delete) a graph and its schema from the TigerGraph database.' It clearly distinguishes itself from clear_graph_data by noting the difference between dropping the whole graph vs. just clearing data. This leaves no ambiguity about what the tool does.

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?

The 'Use When' section explicitly lists the intended scenarios, and both 'Related Tools' and the tips name clear_graph_data and list_graphs as alternatives. It also gives concrete guidance to confirm the graph name first and to use clear_graph_data when only data removal is needed. This is exemplary when-vs-alternative guidance.

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