base_saveDDL

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

The description indicates a side effect (saving a file to the server filesystem), which contradicts the annotations of readOnlyHint: true and idempotentHint: true. This is a clear contradiction, and per the rules, transparency score must be 1.

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 concise and well-structured with sections for arguments and returns. Every sentence adds value, though the format could be slightly streamlined.

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 covers the return type (ResponseType with file path, size, metadata), but lacks details on error handling, prerequisites (e.g., user permissions), or what happens if the object doesn't exist. It is adequate for typical use but not fully comprehensive.

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?

The description provides examples and default values for each parameter, adding meaning beyond the input schema which has 0% description coverage. It explains the purpose of database_name, object_name, object_type (with three examples), and output_dir. However, it could explicitly list allowed object_type values.

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 it extracts the complete DDL of a Teradata object and saves it to a .sql file, using the verb 'Extracts' and specifying the resource. This distinguishes it from sibling tools like base_tableDDL which likely only returns DDL without saving.

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 description mentions it solves the token limit problem, implying when not to use alternatives (when DDL content is small, base_tableDDL might suffice). However, it does not explicitly state when to use this tool vs. siblings, nor does it provide exclusion criteria.

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