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

No annotations are provided, so the description carries the full burden. It conveys that activation enables running, but omits whether the change is reversible, whether it errors on an already-active scenario, permission requirements, and idempotency — all material for a state-mutating tool.

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 short sentence with no waste, and the verb and resource are front-loaded. It is efficient, though it is arguably under-specified rather than optimally concise.

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?

A state-mutating tool with no annotations and no output schema needs to disclose side effects and reversibility. The description gives only the enabling outcome and leaves the agent without enough context to predict the result of the 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 description coverage is 100% and the single scenarioId parameter is already documented as 'Scenario ID to activate'. The description adds no format, type, or sourcing detail beyond the schema, 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 (activate) and resource (scenario), and the clause 'so it can run' hints at the outcome. It does not explicitly distinguish itself from siblings like deactivate_scenario or run_scenario, but the purpose is unambiguous.

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?

'so it can run' implies a workflow ordering (activate before running) but never states when to use this versus deactivate_scenario or run_scenario, nor any prerequisite or exclusion. Usage is inferable rather than 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 of behavioral disclosure, and it discloses nothing: it does not say whether connections, hooks, data stores, or blueprint configuration are copied, whether the clone is active or inactive, what permissions are required, or whether the operation is reversible. 'Clone/duplicate a scenario' is the entire content.

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?

At five words it is certainly short, but the brevity reflects under-specification rather than efficient writing; there is no useful content front-loaded because there is almost no content at all.

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 4-required-parameter mutation tool with no annotations and no output schema, the description is far too thin. It omits what gets duplicated, what the resulting new scenario's state is, and any prerequisites, leaving the agent unable to predict the tool's effect.

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% with all four parameters (name, teamId, scenarioId, organizationId) individually described, so the baseline is 3. The description adds no syntax, format, or constraint detail beyond what the schema already states.

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 concrete verb (clone/duplicate) and resource (scenario), so the operation is unambiguous. However, it essentially restates the tool name 'clone_scenario' and offers no differentiation from nearby siblings such as create_scenario or update_scenario, which an agent could confuse with it.

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 guidance on when to clone versus creating a new scenario, no mention of prerequisites (e.g., needing the source scenario to exist), and no alternatives named. The agent is left to infer usage entirely from the tool name.

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 behavioral burden and delivers none of it: nothing about required permissions, whether the name must be unique, what happens if maxSize is omitted, or what the call returns. For a mutating create tool this is a serious 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?

It is a single short sentence, but the brevity is under-specification rather than conciseness; there is no front-loaded scope or constraint. Nothing is wasted because nothing meaningful is present.

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?

A creation tool with no annotations, no output schema, and a description that omits all behavioral and contextual detail is inadequate for an agent to call it correctly. There is no indication of scope, side effects, or 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% — name, teamId, and maxSize are each documented in the schema — so the baseline of 3 applies. The description adds nothing beyond the schema, but it is not required to compensate for any coverage gap.

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 'Create a new data store' is a near-verbatim restatement of the tool name create_data_store, adding no distinguishing information. It does not differentiate from siblings like create_data_store_record, create_scenario, or clone_scenario. This is the tautology case described in the rubric.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as create_data_store_record (which presumably requires an existing store). The agent gets no help choosing this tool over its siblings.

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 say whether the call requires auth/permissions, what happens on duplicate data, whether 'data' must match the store's schema, or what the response returns — significant gaps for a mutation tool.

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, which is appropriate. It is efficient but so terse that it borders on under-specification rather than exemplary conciseness.

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 mutation tool with no annotations and no output schema, the description is inadequate: it says nothing about required permissions, the expected shape/validation of the nested 'data' object, or the return value. An agent could call it but cannot anticipate failure modes.

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%: dataStoreId and data are both documented in the schema, including the nested-object nature of 'data'. The description adds nothing beyond this, 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?

Clear verb ('Create') plus resource ('record in a data store'), which distinguishes it from create_data_store and create_scenario. However, it offers no explicit contrast with the close sibling list_data_store_records or any hint about what a 'record' must contain, so differentiation is only partial.

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 many other create_* siblings, no preconditions (e.g. the data store must already exist), and no exclusions. The agent must infer usage entirely from the name.

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 burden. It says 'create' but discloses nothing about permissions required, what happens on blueprint validation failure, whether the scenario is created active or inactive, or any side effects. The second sentence only restates what a blueprint is.

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 no filler, and the core action is front-loaded. It is efficient, though the second sentence contributes little beyond restating the term 'blueprint'.

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 5-parameter creation tool with no annotations and no output schema, the description is too thin. It omits required-field emphasis (teamId, blueprint, scheduling are required), says nothing about what the tool returns (e.g., the new scenario ID), and gives no guidance on the blueprint's expected shape beyond one vague sentence.

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 already documents all five parameters, making 3 the baseline. The description adds a small conceptual gloss on the blueprint ('defines the workflow modules and their connections') but no format or constraint detail 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 ('Create a new scenario') and adds that a blueprint is supplied. However, it does nothing to distinguish itself from siblings like clone_scenario or create_data_store, which are also creation tools in this set.

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 and no mention of alternatives such as clone_scenario (copy an existing scenario) or update_scenario (modify one). The agent must infer that this is the right tool for creating from scratch.

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 for a mutation. It does not state whether deactivation is reversible, what happens to in-flight runs, required permissions, or the resulting state beyond 'stops running'.

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. It is efficient, though the clause 'to stop it from running' is somewhat redundant with 'deactivate'.

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 one-parameter mutation the description is minimally adequate, but with no annotations and no output schema it should at least state reversibility and what deactivation does to an already-running scenario.

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 single parameter has 100% schema description coverage ('Scenario ID to deactivate'), so the schema already carries the semantics. The description adds nothing beyond it, making the baseline 3 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 (deactivate) and resource (scenario), and the phrase 'to stop it from running' conveys the effect. It does not distinguish itself from siblings like delete_scenario or activate_scenario, which is the main gap.

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 to use this versus delete_scenario (permanent removal) or activate_scenario (the inverse). The purpose is implied by the verb, but no conditions, prerequisites, or alternatives are named.

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. 'Permanently' is a real disclosure of irreversibility, but nothing is said about cascading effects on related runs/logs, required permissions, or whether the operation can be recovered — significant gaps for a destructive, non-annotated tool.

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 no filler and the key constraint ('permanently') front-loaded. It is efficient, though arguably too terse to be maximally useful.

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 single-parameter tool with no annotations and no output schema, the definition omits the two things an agent most needs: the delete-vs-deactivate decision and the consequences of deletion. The word 'permanently' alone does not make it 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% and the single parameter (scenarioId) is already documented in the schema as 'Scenario ID to delete'. The description adds no syntax, format, or sourcing guidance beyond that, 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 ('delete a scenario') and adds the qualifier 'permanently', which meaningfully distinguishes it from the sibling deactivate_scenario. It does not, however, explicitly name that sibling or contrast the two, so the differentiation is implicit 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?

No when-to-use guidance is given, and there is no mention of the obvious alternative, deactivate_scenario, which is the safer reversible option in the sibling set. An agent must infer on its own when deletion is preferred over deactivation.

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 burden of behavioral disclosure. It implies a read-only operation and authentication requirement via 'Get' and 'authenticated user', but does not state side-effect safety, permissions, rate limits, or return format. It adds minimal behavioral context beyond the purpose.

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 is appropriately sized for a simple getter and communicates its purpose 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?

Given the tool's low complexity (0 parameters, no output schema), the description is adequate but incomplete. Without an output schema, it should explain what information is returned (e.g., fields like id, email, name), and it provides no usage context, leaving gaps for an agent that needs to know the response shape.

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 the baseline score is 4. The empty schema is fully described by its absence of properties, and the description appropriately adds no parameter details since there are none.

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 ('information about the authenticated user'), making the tool's function immediately clear. It does not explicitly differentiate from siblings, but no sibling tool targets the current user, so the lack of explicit comparison is a minor gap.

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 offers no guidance on when to use this tool versus alternatives, nor any prerequisites or context beyond the purpose itself. There is no sentence about when-not-to-use or what other tools might be relevant, leaving usage entirely implicit.

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 burden of behavioral disclosure. 'Get' implies a read-only retrieval, but the description says nothing about permissions, error behavior when the ID is invalid, or whether the operation has side effects, leaving 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?

The description is a single, front-loaded sentence with no wasted words. It is efficient, though its extreme brevity contributes to the gaps in usage and behavioral guidance rather than being an unalloyed strength.

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 low-complexity, single-parameter retrieval tool with full schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should do more to explain the retrieval's behavioral context and how it differs from sibling listing tools.

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 dataStoreId parameter is already documented in the schema. The description adds no syntax, format, or meaning beyond what the schema provides, which matches the baseline of 3 when the schema does the heavy lifting.

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 ('details of a data store'), so the core action is clear. However, it does not distinguish this single-store lookup from the sibling list_data_stores, nor does it clarify that the lookup is by ID, leaving sibling differentiation implicit.

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 guidance on when to use this tool versus alternatives such as list_data_stores or list_data_store_records, and no prerequisites or exclusions are stated. The agent must infer usage entirely from the tool name and 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, yet it only restates the read action. It says nothing about permissions, whether the scenario must exist, error behavior for an invalid scenarioId, or what 'details' includes.

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, front-loaded with the verb and resource, with no filler. It is efficient, though its brevity comes at the cost of any elaboration.

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 simple single-parameter read tool with no nested objects and no output schema, so the burden is modest. Still, the description leaves the agent without any indication of the return shape or error conditions for a lookup that requires a valid ID.

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% for the single scenarioId parameter, so the schema already documents the required input. The description adds no syntax, format, or sourcing detail beyond what the schema provides, which is the expected baseline when schema coverage is complete.

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 ('details of a specific scenario'), so the core action is unambiguous. It does not distinguish itself from close siblings like get_scenario_blueprint or get_scenario_logs, which also retrieve scenario-related information.

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 when-to-use guidance and no alternatives named. In a cluster containing list_scenarios, get_scenario_blueprint, get_scenario_logs, and get_current_user, an agent gets no help deciding which retrieval tool to pick.

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 burden. 'Get' implies a read-only operation, but the description does not disclose any other behavioral traits such as authentication requirements, rate limits, error behavior, or what 'full blueprint' entails structurally.

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 is appropriately sized for 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?

With no output schema and no annotations, the description should compensate by describing the return value or key behavioral aspects. It does not explain what a blueprint contains (e.g., nodes, edges, flow logic) or any other details an agent would need to use the tool confidently.

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 scenarioId parameter is fully documented in the schema. The description adds no additional meaning about the parameter, which is acceptable given the high 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 states a specific verb ('Get') and resource ('full blueprint (flow definition) of a scenario'), which distinguishes it from the sibling get_scenario by focusing on the flow definition. However, it does not explicitly contrast itself with get_scenario or other siblings, so it stops short of full 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?

There is no guidance on when to use this tool versus get_scenario, list_scenarios, or any other alternative. The description gives no context for selection or exclusions.

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 provided, so the description carries full behavioral burden. It doesn't disclose whether logs are returned in chronological order, whether they include timestamps, how large they can be, pagination behavior, or any read-only/safety characteristics. Minimal disclosure.

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?

Single, efficient sentence with no waste. Front-loads the action and resource. However, it's very terse, which borders on under-specification rather than optimal conciseness.

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, no annotations, and the description is only five words. It doesn't explain return format (e.g., plain text vs structured objects), ordering, size, or any limitations. Grossly incomplete for a tool that retrieves potentially large logs.

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. The description adds no extra meaning about scenarioId or limit. Baseline 3 applies because schema does the heavy lifting.

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?

Clear verb+resource: 'Get execution logs for a scenario'. Distinguishes from get_scenario (which likely returns scenario metadata/definition) by specifying logs. Reasonably distinct from siblings, though not explicitly contrasted.

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 to use this tool versus alternatives. It doesn't mention prerequisites (e.g., scenario must have been run), rate limits, or whether logs are retained. An agent must infer usage from the name 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 full behavioral burden, and it discloses nothing beyond the operation itself. Critically, for a tool that returns API credentials it never says whether secret values are returned in full or masked, nor does it mention pagination behavior implied by the limit parameter. Permission/auth requirements are also 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 tight sentence with the resource and its scope front-loaded and no wasted words. Nothing could be cut without losing meaning.

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 with no output schema and no annotations, the description is minimally adequate: an agent knows what it lists and for whom. It falls short on return-value expectations and any indication of how credentials are exposed, which matters for a security-sensitive list.

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 (teamId, limit) are already documented in the schema, making 3 the baseline. The description adds only that connections belong to a team, reinforcing teamId, but adds nothing about limit or result behavior.

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 (List) and resource (connections) and defines the resource inline as 'API credentials' and scopes it to a team. It does not need to distinguish itself from siblings, which are all unrelated (scenarios, data stores, teams), so the lack of sibling differentiation is not a real gap.

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 implied by the name and the team-scoping language, but there is no explicit statement of when to call this versus other list tools nor any prerequisite note. For a simple list primitive the implied context is largely sufficient, so a mid score is appropriate.

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 burden of behavioral disclosure. It implies a read-only list operation but says nothing about pagination behavior, default limits, permissions required, or the shape of returned records, which are important for a list tool with a limit parameter.

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 is appropriately sized for a simple list operation and every word earns its place.

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 lack of annotations and output schema, the description should do more to explain behavior, return values, or usage context. It is too minimal to be complete for an agent that needs to know how to call this tool correctly beyond the basic schema.

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 the dataStoreId and limit parameters are already documented in the schema. The description adds no additional meaning about parameter formats, defaults, or constraints, making a baseline 3 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?

The description states a specific verb (list) and resource (records in a data store), clearly distinguishing this from listing data stores or retrieving a single store. However, it does not explicitly differentiate from the sibling create_data_store_record or mention any scope limitations, so it falls short of full 5-level 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?

There is no guidance on when to use this tool versus alternatives such as get_data_store or list_data_stores, nor any mention of prerequisites or exclusions. The description only states what it does, leaving usage context entirely to inference.

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 discloses nothing about pagination, the meaning of the limit parameter, ordering, or whether results are scoped by permissions. For a list operation with an undisclosed cap parameter, this is a notable 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 resource and scope front-loaded; there is no filler. It is efficient but borders on under-specification rather than excess.

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 and no annotations, the description covers the essentials. It falls short on the limit/pagination behavior, which an agent needs to page results 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 documented in the schema itself, establishing a baseline of 3. The phrase "for a team" merely echoes the required teamId and adds no format or constraint detail 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?

The description states a specific verb ("List") and resource ("data stores") with the scoping qualifier "for a team". It does not, however, distinguish itself from siblings like get_data_store or list_data_store_records, so an agent must infer the boundary.

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 indication of when to use this versus get_data_store (single store) or list_data_store_records (records within a store). No prerequisites or exclusions are given; the agent must infer usage from the name 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?

With no annotations, the description carries the entire behavioral burden, yet it only conveys that this is a read of team-scoped data. It says nothing about required permissions/admin scope, whether the result is paginated, how the 'limit' interacts with total results, or what the returned hook objects contain.

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 action, resource, and scope in the first few words. Nothing is padded 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 simple two-parameter read with no output schema and no annotations, the description covers purpose and scope but leaves the return shape and pagination semantics unstated. Adequate to call the tool, but thin for a tool an agent must interpret results from.

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% ('Max results', 'Team ID'), so the schema already documents both parameters. The description adds only that hooks are scoped to a team, which marginally clarifies teamId but adds no syntax or format detail, making the baseline 3 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?

The description names a specific verb ('List') and resource ('webhooks') scoped to a team, so an agent knows exactly what comes back. No sibling tool lists hooks, so there is no confusion to disambiguate, but the description does nothing explicitly to distinguish itself from the surrounding list_* tools.

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 alternatives, no prerequisites, and no mention of what a caller needs in hand before invoking it. The only implicit guidance is that a team is required, which the schema already states.

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 results are scoped to the user's access, but says nothing about pagination behavior (despite a limit param), ordering, or result 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?

One efficient sentence with the resource and scope front-loaded; there is no filler or 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 simple no-arg list tool with no output schema, the definition covers the essentials. It is adequate but leaves pagination and result expectations 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 coverage is 100% and the single limit parameter is already documented in the schema, so the baseline applies. The description adds no meaning 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 clear verb+resource: 'List all organizations' with the scope 'the user has access to'. This distinguishes it from resource siblings like list_teams and list_scenarios, but it offers no explicit contrast with any of 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 when-to-use guidance, no prerequisites, and no mention of alternatives. The access-scope qualifier is the only usage signal, implied rather than 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, yet it says nothing about this being a read-only operation, how pagination behaves, ordering, or what the result set contains. 'List all' even overstates the result, since limit and offset exist in the schema.

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 verb and scope front-loaded and zero filler. It is efficient, though arguably under-specified rather than optimally concise.

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 four parameters, the description should do more: it omits pagination semantics, default ordering, and the shape of the response. An agent can call it, but cannot predict its behavior or output without trial.

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 already explains limit, offset, teamId, and organizationId, making 3 the baseline. The description's 'for a team or organization' mirrors the schema's either-or requirement but adds no syntax, default, or behavioral 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 (List) and resource (scenarios) with a scope qualifier (for a team or organization), so the operation is unambiguous. It does not, however, distinguish itself from siblings like get_scenario or list_scenarios-style alternatives, leaving differentiation to inference.

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 gives no when-to-use guidance, no prerequisites, and never names an alternative tool such as get_scenario for single-record retrieval. The only implicit hint is the phrase 'for a team or organization', which loosely signals the teamId/organizationId choice but is not framed as guidance.

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 discloses nothing beyond the basic operation: no permission/auth requirements, no pagination or limit behavior, and no note on whether the result set is truncated. The phrase 'all teams' is also left in tension with the presence of a limit parameter.

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 resource and scope front-loaded and no filler. It is efficient, though it is arguably too terse to be fully useful.

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 full schema coverage and no output schema, the description is minimally sufficient. It still omits pagination/limit semantics and any indication of result size or permissions, which an agent would need to call it confidently.

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, and the description adds no syntax, format, or range detail for organizationId or limit. Baseline 3 applies when the schema does the heavy lifting.

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 (list) and resource (teams) plus the scoping container (an organization), so the operation is unambiguous. It does not differentiate from siblings, though none of the listed siblings cover teams, so there is little risk of confusion.

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 guidance on when to call this versus another tool, no prerequisites, and no exclusions. The only implied usage is that an organizationId is needed, which the schema already enforces.

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 full behavioral burden. It usefully discloses the on-demand/active scheduling precondition, which is a real constraint not in the schema, but says nothing about side effects, permissions, whether the run blocks, or failure 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?

Two short sentences with zero waste; the action is front-loaded and the precondition follows immediately. Every sentence earns its place.

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 trigger/mutation tool with no annotations, no output schema, and a free-form nested 'data' object, the description leaves key gaps: what the run returns, whether it is synchronous, and what happens if the scenario is not on-demand. Only the scheduling precondition is covered.

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 scenarioId, data, and responsive are all documented in the schema. The description adds no parameter-level detail beyond what the schema already 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 (Run) and resource (scenario), and 'immediately' distinguishes it from the get/list/create/update/activate siblings. It is clear what the tool does, though it does not explicitly name which sibling to prefer over it.

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?

Provides a precondition for use: the scenario must be active and set to on-demand scheduling. That implies 'when to use' but gives no explicit exclusions or named alternatives (e.g. why not activate_scenario first).

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 burden for this mutation tool. It does not say whether the update is partial or full-replace, whether omitted fields are preserved, whether permissions are required, or what side effects occur if the scenario is active. Only the word 'Update' signals mutation.

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 verb and resource come first and the field list is compact. It is efficient, though the parenthetical field enumeration duplicates the schema and could be dropped or replaced with more useful behavioral detail.

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 and no output schema, the agent needs to know update semantics (partial vs. full), validation behavior, and side effects. None of this is present, leaving the definition incomplete for a write operation touching five fields.

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 and the schema already documents each field in detail. The description restates the field set but adds nothing new, and it says 'folder' where the parameter is actually folderId, a minor naming looseness rather than added meaning.

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 (Update) and resource (scenario) and enumerates the affected fields (name, blueprint, scheduling, folder), so the agent knows exactly what changes. It does not, however, differentiate itself from siblings like create_scenario or activate_scenario beyond the verb, which the sibling names already imply.

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 to use this versus alternatives. The sibling list contains activate_scenario, deactivate_scenario, and clone_scenario, and nothing tells the agent whether toggling state belongs here or in those tools. The agent must infer prerequisite conditions (e.g., scenario must exist) on its own.

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