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

No annotations are provided, so the description carries the behavioral burden. The verb 'Get' implies a read-only operation, but the description does not explicitly confirm no side effects, describe error behavior when no database is active, or explain the returned context's shape.

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 a single, front-loaded sentence with no filler. Every word contributes to stating the tool's purpose.

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 zero-parameter getter with no output schema, the description gives enough conceptual information to call the tool correctly. It could be stronger by clarifying what 'database context' includes (e.g., name, ID) or what happens when no database is selected.

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 tool has zero parameters, so there are no parameter semantics to document. The baseline score of 4 applies; the description correctly does not invent or omit parameter details.

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 states a specific verb (Get) and resource (current database context), making the tool's purpose immediately clear. It is distinct from list_databases and use_database, though it does not explicitly name those siblings.

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 implies the tool is used to inspect the active database, but provides no explicit guidance on when to call it versus alternatives like list_databases or use_database. There are no exclusions or contextual triggers.

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

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

With no annotations provided, the description carries the full disclosure burden but says nothing about read-only behavior, required permissions, error behavior on an unknown table, or how the optional database parameter resolves. It only implies a read operation through the verb 'Get'.

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 efficient sentence with the resource front and center and no filler. It is slightly under-specified rather than verbose.

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 two-parameter read tool this is close to adequate, but with no output schema the description never says what 'column information' contains (names, types, nullability, keys). That is a meaningful gap an agent must discover empirically.

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%, and the schema itself explains both the table name and the optional database fallback to TD_DATABASE. The description adds no syntax, format, or qualification details beyond that, so baseline 3 applies.

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 names a specific verb and resource ('Get column information for a specific table'), which is clearly distinct from siblings like list_tables or query. It does not, however, explicitly contrast itself with those siblings.

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 statement of when to use this tool versus list_tables, query, or use_database. The intended usage (inspecting schema before composing a query) must be inferred entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that this performs writes and requires enable_updates=true, but says nothing about irreversibility, affected rows, transactions, permissions, or return behavior.

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 short sentence that is front-loaded with the purpose and ends with the key prerequisite. It contains no redundant explanation.

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 write-capable SQL execution tool with no annotations and no output schema, the description is thin. It conveys the enable_updates gate but omits safety, side effects, and result expectations that an agent would need before invoking it.

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?

There is only one parameter, sql, and schema coverage is 100% with the schema already describing it as the SQL statement to execute. The description adds no additional syntax or formatting guidance beyond the schema.

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 (execute) and resource category (write operations), with examples UPDATE, DELETE, INSERT. It is clearly distinct from the likely read-only sibling query, though it does not name that sibling explicitly.

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?

Gives one concrete usage condition: enable_updates=true. However, it does not explicitly say when not to use it or name the read-oriented query alternative, so the agent must infer the routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies read-only, but nothing is said about permissions, pagination, ordering, or whether the attempt_id must belong to the caller; for a task-listing tool this leaves important operational context unstated.

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 efficient sentence with the core scope front-loaded. It is not padded, though it could have used one more clause to state the alternative or return shape.

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 two-parameter read tool with no output schema, the description is minimally adequate. It omits return shape, whether status is per-task or aggregate, and how subtasks are represented, which an agent would benefit from knowing.

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 both attempt_id and include_subtasks are documented in the schema. The description adds no extra meaning about include_subtasks (e.g., nesting behavior) or attempt_id format, which is acceptable at baseline 3 but not more.

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 states a specific verb and resource ('List all tasks within an attempt') and adds the execution-status angle. It is clear what the tool returns, though it does not distinguish itself from siblings like get_task_logs or get_session_attempts.

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 use this tool versus get_task_logs, get_session_attempts, or retry_attempt. The agent must infer that this is the task-enumeration step before fetching logs.

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

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

With no annotations, the description carries the full burden. It discloses the EXPERIMENTAL status and the ID-discovery prerequisite, but says nothing about what 'details' are returned, permissions, or error behavior for an invalid ID. Adequate for a simple read getter but leaves behavioral gaps.

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?

Three short sentences, front-loaded with the EXPERIMENTAL tag and the core action. Slight redundancy where it restates the required parameter already covered by the schema, but otherwise efficient.

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?

No output schema and no annotations, so the description should ideally say what 'details' comprise. For a simple single-ID getter it is mostly sufficient, but the return shape is left entirely to inference.

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% and the single parameter is fully documented in the schema, including the list_parent_segments hint. The description's 'Requires parent_segment_id parameter' merely repeats the schema, adding no syntax or format detail beyond it.

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+resource: 'Get details of a specific parent segment by its ID,' which clearly distinguishes it from the sibling get_segment (which operates on segments, not parent segments). The distinction is implied through the resource noun rather than explicitly contrasted, but an agent can tell them apart.

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?

Explicitly tells the agent to call list_parent_segments first to discover valid IDs, giving a concrete prerequisite workflow and naming the alternative for discovery. No explicit when-not-to-use condition, but the intended usage path is clear.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses experimental status, required IDs, and that the result includes filtering rules, but it does not state read-only/side-effect behavior, permissions, pagination, or fuller return characteristics.

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 three compact sentences, with the experimental flag and purpose front-loaded, followed by prerequisites and ID discovery guidance. Every sentence supports correct invocation, with no filler.

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 two-parameter get tool, it covers the purpose and the ID discovery prerequisites. However, with no annotations and no output schema, it should say more about the return payload and whether the operation is strictly read-only.

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 both parameters are already fully documented in the schema. The description only repeats that both are required and points to the list tools for finding IDs; it adds no format or semantic detail beyond what the schema provides.

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, 'Get detailed information,' and a specific resource, 'a specific segment,' including its filtering rules. It distinguishes this from the list_* discovery tools by saying to use those first, though it does not explicitly contrast with get_parent_segment or segment_sql.

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 states the prerequisite that both parent_segment_id and segment_id are required and tells the agent to use list_parent_segments and list_segments first to find IDs. This gives clear context for when to call it, but it does not state when not to use it or name an alternative for detailed segment data.

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

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

No annotations exist, so the description carries the full burden and largely fails: it never confirms this is a read-only operation, says nothing about result volume, pagination, or ordering for potentially many attempts. Only 'all attempts' hints at an unpaginated list return.

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?

One efficient, front-loaded sentence with no filler. The phrase 'detailed information' is the only slightly vague element, but nothing is wasted.

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 and no output schema, the description should say what an 'attempt' object contains and whether the list is bounded. It covers the input scoping adequately but leaves the return shape and read-only nature undocumented.

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 100% and the single parameter is already documented as 'Session ID', so the description's 'for a specific session' adds nothing new. Baseline 3 applies; it does not explain where the session_id comes from (e.g., list_sessions).

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 ('Get') and resource ('all attempts for a specific session'), which is clearly distinct from siblings like list_sessions or get_attempt_tasks. It stops short of explicitly distinguishing itself from get_attempt_tasks (which appears to drill one level deeper).

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?

Usage is only implied by the scoping phrase 'for a specific session'; there is no explicit when-to-use/when-not or named alternative among the many siblings. An agent can infer this is the per-session attempt listing, but must guess how it relates to list_sessions and get_attempt_tasks.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only says "retrieve." It does not disclose read-only semantics, whether logs are complete or capped (the limit parameter hints at truncation but the description never says so), whether logs expire, or what the response shape looks like.

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 single sentence is front-loaded and free of filler, but it is underspecified rather than concise — the same length could have carried a scoping note or an alternative-tool pointer without bloat.

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 and no output schema, the description is the only source of behavioral context for a four-parameter, task-scoped log retrieval tool, and it supplies none. Pagination semantics, truncation behavior, and the relationship between attempt_id and task_name are all left unaddressed.

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 all four parameters (limit, offset, task_name, attempt_id) are already documented with formats and examples in the schema. The description adds no additional meaning beyond that baseline; a 3 is the appropriate ceiling here.

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 names a specific verb and resource ("Retrieve logs for a specific task"), so the agent knows exactly what data is returned. It does not differentiate from nearby siblings such as get_attempt_tasks or get_session_attempts, which also take attempt/task identifiers, leaving ambiguity about which tool surfaces logs versus task metadata.

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 statement of when to use this tool versus the sibling attempt/task tools, and no prerequisites (e.g., that a task must exist within an attempt, or that logs may be truncated or expired). The agent must infer the calling conditions entirely from the schema.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Request cancellation" hints that cancellation may be asynchronous rather than immediate, but the description does not disclose permissions, whether cancellation is graceful or forced, reversibility, or what the caller should expect after invoking it.

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 a single, front-loaded sentence with no filler. It is concise, though its terseness contributes to the gaps in behavioral guidance rather than making it maximally informative.

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?

This is a mutation tool with no annotations and no output schema, and the description does not explain permissions, side effects, asynchronous behavior, or expected response. For an attempt-cancellation operation, those omissions leave the agent without important operational context.

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 schema itself fully documents attempt_id and reason. The description adds no additional parameter meaning, which is acceptable given the schema's completeness but does not exceed the baseline.

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 states a specific action ("Request cancellation") and target ("a running attempt"), which is clear enough for an agent to understand what the tool does. It does not, however, distinguish this from sibling tools such as retry_attempt or explain how it relates to 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?

The phrase "running attempt" gives implied usage context: this tool applies only to attempts that are still running. There is no explicit when-not guidance, no mention of retry_attempt as an alternative, and no prerequisites or conditions beyond that implied scope.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool is EXPERIMENTAL and requires specific identifiers, but it does not state permissions, pagination behavior, return shape, or rate-limit considerations for this list operation.

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 three short sentences, front-loads the EXPERIMENTAL marker, and then states scope and prerequisites with no wasted text. Every sentence contributes directly to correct invocation.

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 two-parameter list tool with no output schema, the description supplies the essential context: resource, scope, required IDs, and how to find them. It stops short of describing return contents or pagination, which would improve completeness.

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 both parameters are already documented in the schema, including their required status and discovery path. The description reiterates that both are required and points to the same list tools, adding little beyond the structured schema.

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 specific verb and resource ('List all activations (syndications)') and scopes it to a specific segment. It also marks the tool as EXPERIMENTAL and clarifies the parent/child segment relationship, making its role distinct from segment-listing siblings.

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 clearly states prerequisites: both parent_segment_id and segment_id are required, and it directs the agent to call list_parent_segments and list_segments first to discover IDs. It does not describe when not to use this tool or name a direct alternative for listing activations.

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

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

No annotations are provided, so the description carries the burden. 'List all available' implies an unfiltered, read-only enumeration with no parameters, which is useful scope information, but it says nothing about pagination, permissions, or the shape of returned entries.

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 no filler; the resource and scope arrive immediately.

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 zero-parameter list tool this is nearly complete — the agent knows it returns all databases. With no output schema, a brief note on what each database entry contains would have closed the remaining gap.

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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming the call is argument-free. Baseline 4 applies.

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 ('List all available databases') and names the product scope ('in Treasure Data'). It is clearly distinct from siblings like list_tables or describe_table, though it does not explicitly contrast itself 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?

No guidance on when an agent should call this versus alternatives such as use_database or current_database. The agent must infer trigger conditions from the sibling names alone.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool is experimental, lists all parent segments, and takes no parameters, which implies a read-only exhaustive listing. It does not describe pagination, permissions, or response behavior.

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 two short sentences with no wasted text. The experimental status is front-loaded, followed by the core purpose and parameter requirement.

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 zero-parameter list tool, the description is minimally sufficient: it names the resource and confirms no input is needed. However, with no output schema and no annotations, it lacks any explanation of return shape or pagination behavior.

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 tool has zero parameters, and the description correctly states that no parameters are required. With no parameters to document, this meets the baseline for adequate semantic coverage.

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 and resource: "List all parent segments (audiences)" in Customer Data Platform. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as list_segments or get_parent_segment.

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 states that no parameters are required, but gives no guidance on when to use this tool versus list_segments, get_parent_segment, or list_activations. There is no when-to-use or when-not-to-use context.

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

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

No annotations are supplied, so the description carries the full burden, yet it only implies a safe read via the word "List." It says nothing about result ordering, the default/maximum cap of 100, how the pagination cursor behaves, or what happens when the list is empty.

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 no filler or redundancy. Its brevity is not wasteful in structure, though it veers toward under-specification rather than tightness.

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 an unannotated list tool with no output schema and a shared hierarchy of siblings, the description omits what a project is relative to workflows and databases and what a result record looks like. The scope an agent needs to call this correctly and interpret the response 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% – both `limit` (default 100) and `last_id` (pagination cursor) are documented in the schema itself. The description adds nothing about them, which is acceptable under the baseline rule but deserves no credit above 3.

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?

"List all workflow projects" gives a specific verb (List) and resource (workflow projects), so the basic operation is clear. However, it does not distinguish this from the nearby sibling list_workflows or list_databases — an agent cannot tell whether a "project" is a container above workflows or an alias for 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 guidance, no mention of alternatives such as list_workflows, and no stated preconditions despite an explicitly related sibling set. The agent must infer that this is the enumeration entry point for the project hierarchy.

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

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

No annotations exist, so the description carries the burden. It usefully discloses the [EXPERIMENTAL] stability caveat and the required prerequisite, both of which are behavioral signals not present in structured fields. However, it says nothing about read-only semantics, pagination, result volume, or what a segment listing contains, which are material gaps for a listing tool with zero annotation coverage.

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?

Three short sentences, front-loaded with the experimental flag and the core action, then the prerequisite. It is efficient, though the parent-ID guidance duplicates the schema description almost verbatim, costing a little redundancy.

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 single-parameter read tool with no output schema and no annotations, the description covers the action, the required input, and how to obtain it. The main omission is the shape of the returned segments, which the agent must infer on first call.

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 100% and the single parameter is fully described in the schema, including the recommendation to use list_parent_segments. The description repeats this same information rather than adding format, type, or edge-case meaning, so baseline 3 applies.

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 specific verb and resource ("List all segments under a specific parent segment") and immediately scopes it by parent, which distinguishes it from the sibling list_parent_segments. It stops short of explicitly contrasting with get_segment or segment_sql, so the differentiation is implied rather than stated.

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 provides a concrete prerequisite workflow: call list_parent_segments first to obtain a valid parent_segment_id. There is no explicit when-not-to-use guidance or naming of get_segment/segment_sql as alternatives for single or SQL-level access, but the ordering context is clear.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation but never states read-only safety, result ordering, default page size behavior, or what happens when limit/last_id interact. For a 7-parameter listing tool with zero annotation coverage, this leaves significant behavioral gaps.

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 short, front-loaded sentence with no filler or repetition. It is efficient, though its brevity is largely a byproduct of leaving details unstated rather than a deliberate compression.

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?

Given 7 optional parameters, no annotations, and no output schema, the description should clarify pagination behavior and result shape or ordering. It does none of these, so an agent could invoke it but would not understand what it gets back or how to page correctly.

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 every parameter (limit, status, last_id, from_time, to_time, project_name, workflow_name) is already documented in the schema. The description adds nothing beyond that, so the baseline 3 is appropriate.

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+resource: 'List workflow execution sessions', which is distinguishable from list_workflows, list_projects, and get_session_attempts. However, it doesn't clarify the relationship to the session-related siblings (get_session_attempts, retry_session) or confirm the scope of 'workflow execution sessions'.

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?

'with filtering options' is the only usage hint, and it provides no guidance on when to use this versus list_workflows or get_session_attempts. Nothing explains when filters should be applied, whether all filters can combine, or how the cursor pagination should be driven.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List all tables' implies a read-only, non-destructive operation and gives scope, but the description does not mention permissions, pagination, whether views or system tables are included, or what happens with an empty/missing database.

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 a single front-loaded sentence with no wasted words. It states the operation and scope immediately and is appropriately sized for the tool's simplicity.

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?

Given the low complexity, one optional parameter with full schema coverage, and no output schema, the description is complete enough to call the tool correctly. Minor gaps remain around return shape and edge cases, but they are not severe for a simple list operation.

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 single optional database parameter is already fully documented in the schema. The description reinforces the database scoping intent but adds no syntax, format, or default behavior beyond what the schema provides.

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 states a specific verb and resource: list tables. It also scopes the operation to a specific database, making the purpose clear, though it does not explicitly distinguish itself from sibling tools such as list_databases or describe_table.

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 implies when to use the tool by mentioning 'a specific database', but gives no explicit guidance on when to use it versus alternatives such as list_databases or describe_table. There are also no exclusions or prerequisite notes.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose pagination behavior, the default limit, permissions, or what the returned workflow objects contain; 'List' alone leaves the agent to infer read-only safety and read semantics.

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 with the core purpose front-loaded and no wasted words. It is perhaps too terse for the gaps it leaves, but structurally it is efficient and well-ordered.

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 read tool with fully documented parameters, the description is minimally adequate. However, with no annotations and no output schema, it should say more about return shape or pagination behavior to be complete.

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 restates the optional project_name filter already documented in the schema and adds no syntax, matching, or pagination guidance beyond it.

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 ('List workflows'), which is enough for an agent to distinguish it from siblings like list_projects or list_databases. It does not explicitly name a sibling it replaces or contrast with one, so it falls short of a 5.

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 only guidance is 'Optionally filter by project name,' which is parameter behavior rather than a when-to-use rule. There is no indication of when to choose this over list_projects or other list tools, and no prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the tool is marked [EXPERIMENTAL] and it is a read-style 'get'. It says nothing about permissions, whether the SQL is generated or stored, or what the response looks like, which leaves meaningful behavioral gaps for a tool with zero annotation coverage.

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?

Three short sentences, front-loaded with purpose followed by the required parameter and the discovery step. Nothing is redundant, though the parameter sentence largely duplicates the schema and could be trimmed.

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 one-parameter read tool with no output schema and no annotations, the description covers discovery and prerequisite but not the nature of the returned SQL (e.g., full statement vs snippet, dialect, format). An agent can invoke it, but not anticipate the result.

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% and the single parameter is documented in-schema, so the baseline is 3. The description merely restates that parent_segment_id is required and points to list_parent_segments, adding no format or semantics beyond the schema.

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: 'Get the SQL statement for a parent segment (audience)', which is concrete and names what is retrieved. It does not explicitly differentiate itself from the sibling segment_sql or query tools, so an agent must infer that this one is scoped to parent segments.

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 gives a useful prerequisite workflow ('use list_parent_segments first'), which is real guidance for finding the ID. However, it never says when to choose this over segment_sql, get_parent_segment, or query, nor does it state any exclusions, so the usage context is only implied.

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

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

With no annotations, the description carries the burden and does usefully disclose the read-only constraint and the permitted statement classes, which is meaningful behavioral context. It omits permissions/auth requirements, timeouts, whether results are truncated, and how errors surface — significant gaps for a query-execution tool with zero annotation coverage.

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 sentences, zero waste: purpose and dialect first, then the single most valuable performance tip. Nothing is buried or redundant.

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 2-parameter tool with a fully described schema, the description covers dialect, statement types, and performance guidance adequately. But with no annotations and no output schema, it says nothing about what a result set looks like, how rows/columns are returned, or what happens on query failure — details an agent would want before invoking a raw SQL executor.

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 both `sql` and `limit` are already well documented, including UDF examples and the default/max row limits. The description repeats the td_interval performance advice already present in the schema, adding little beyond it; baseline 3 applies.

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 (Execute) and resource (read-only SQL query) and narrows scope with the allowed statement types (SELECT, SHOW, DESCRIBE) and Trino dialect. It clearly separates itself from list_databases/list_tables/describe_table, but it does not distinguish itself from the sibling tool named 'execute', which is the most likely confusion point.

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 second sentence gives a concrete usage condition for td_interval on large tables, which is genuinely actionable. However, there is no guidance on when to prefer this tool over the sibling 'execute' or over describe_table/list_tables, and no prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden and largely drops it: nothing is said about whether a retry creates a new attempt or reuses the ID, whether it is idempotent, what side effects (logs, task re-execution, cost) occur, or what permissions are needed. Since this is a state-changing operation, the absence of any disclosure is a significant gap.

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 short sentence with the core action front-loaded and no filler. It is efficient, though the compactness is partly achieved by omitting information rather than by tight phrasing.

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 mutation tool with no annotations, no output schema, and a nested object parameter whose inner shape is undocumented, the description should explain return/effect semantics and the retry-vs-resume behavior. Instead it stops at ten words, leaving an agent unable to predict what the call produces.

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 attempt_id, force, resume_from and retry_params are already documented in the schema; baseline is 3. The phrase "resume capabilities" loosely signals resume_from, but the description adds no semantics for force or for the structure of the nested retry_params overrides.

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 ("retry") and resource ("a specific failed attempt"), which tells an agent precisely what the tool acts on. It does not, however, distinguish itself from the sibling retry_session, leaving the attempt-vs-session granularity to be inferred from the name alone.

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 statement of when to use this versus retry_session, no precondition that the attempt must be in a failed state, and no guidance on when resume_from or force apply. The only usage hint is the word "failed" and the vague "with resume capabilities".

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

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

No annotations are provided, so the description carries the full behavioral burden, and it falls short. It does not say whether retrying creates a new attempt, what happens to the prior failed attempt's state, whether the call is synchronous or queued, or what permissions/conditions are required to retry.

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 the two retry modes stated compactly and no wasted words.

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 mutation-style action tool with no annotations, no output schema, and a free-form nested retry_params object, the description is too thin. It says nothing about the return value (e.g., a new attempt ID), success/failure conditions, or how retry_params is shaped.

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 100%, so baseline is 3, but the description earns an extra point by clarifying that omitting from_task retries "from the beginning" — semantics the schema's "Task name to retry from" does not convey. retry_params is left unexplained, but the schema covers it.

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 (retry a session) plus the two modes of retry (from start or from a task). It distinguishes itself reasonably from retry_attempt by operating on sessions, but never explicitly contrasts with that sibling, which a reader must infer from the names alone.

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?

"Retry a failed session" implies a precondition (session must have failed), but the description never states that as a requirement, nor does it route the agent between retry_session, retry_attempt, and kill_attempt. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the burden well: it marks the tool as EXPERIMENTAL and clarifies that it returns a SQL statement with filtering conditions applied rather than executing anything. It omits permission or failure behavior, but for a simple retrieval tool this is reasonably transparent.

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 front-loaded with the experimental status and core purpose, followed by requirements and prerequisite tools. It is efficient, though the required-parameter sentence partly repeats what the schema already enforces.

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 two-parameter retrieval tool with fully described schema fields and no output schema, the description covers purpose, required inputs, and how to obtain IDs. It could more explicitly contrast with parent_segment_sql, but otherwise it is complete enough to invoke correctly.

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 both parameters are already documented in the schema, including the sibling lookup tools. The description reinforces that both IDs are required but adds no syntax or semantic detail beyond the structured fields.

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 states a specific verb and resource: get the SQL statement for a segment with filtering conditions applied to the parent segment SQL. It clearly distinguishes this from retrieving the parent segment SQL alone, which helps an agent separate it from sibling parent_segment_sql.

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 gives clear prerequisite guidance by naming list_parent_segments and list_segments to find the required IDs. It does not explicitly state when to prefer this over parent_segment_sql, so it stops short of full alternative routing.

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

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

With no annotations, the description carries the full burden. It does disclose the key behavioral trait that this mutates session state affecting later calls, which is valuable. However, it omits whether the context persists across sessions, whether an invalid database errors, and what permissions are required.

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 zero waste. The stateful implication is placed where the agent will read it first.

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 one-parameter tool with no output schema and no annotations, the description covers the essential statefulness needed to call it correctly. Only minor gaps remain, such as error behavior on an unknown database name.

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 single 'database' parameter is already documented in the schema. The description adds no syntax, format, or naming-convention detail beyond what the schema provides, so the baseline 3 applies.

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+resource: 'Switch the current database context.' This is clearly distinct from siblings like query, execute, and list_databases. It stops short of naming an alternative, so it doesn't reach the 5 level of explicit sibling 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?

'for subsequent queries' implies the usage context (call this before running queries against a different database), but there is no explicit when-to-use, when-not-to-use, or named alternative such as list_databases for discovering valid names.

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